►
From YouTube: WebRTC Working Group Virtual Interim September 13, 2017
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).
C
B
C
Right
so
our
starting
with
some
issues
related
to
tracks.
This
first
issue
is
that,
due
to
the
changes
we
need
to
support
early
media
me
receiving
media
before,
and
answers
received,
an
RTP
receiver
along
with
media
stream
track,
is
created
at
offer
time
rather
than
answer
time
and
that
track.
You
know
it's.
This
ID
can't
change
after
creation.
That
would
mess
things
up.
So
you
know
the
situation.
C
We're
in
is
that
the
the
track
ID
from
the
answer
or
even
from
remote
offers
a
lot
of
the
time
is
only
to
end
up
ignored
and
the
track
will
just
end
up
with
a
generated
ID
that
it
was
determined
when
you
call
add
track
where
a
transceiver,
and
this
could
be
a
problem
for
applications
that
are
relying
on
using
the
track
ID
to
signal
something.
You
know,
for
example,
signaling
this
this
track.
C
So
you
could
get
around
this
problem
by
just
switching
to
using
mids
to
signal
this
meeting
instead.
So
you
know
that
the
track
event
does
tell
you
which
transy
the
track
is
associated
with
and
you
can
go
instead
of
certainly
me
with
track.
Ids
you
can
signal,
means
missus
that
maybe
there's
been
more
code
to
write,
but
that's
the
works
on,
but
we're
applications
that
don't
want
to
use
track,
IDs
jump,
but
this
pretty
simple
addition
to
the
spec
that
provides
that
information
without
having
to
make
that
application
farce
STP
itself.
C
D
Or
other
changes
Taylor.
Let
me
just
ask
a
couple
questions
here:
basically,
I'm:
okay,
with
this
proposal,
I,
don't
think
it
should
be
called
track.
Id
I
think
it
should
be
called
app
data
because
that's
actually
what
it's
called
in
the
SDP
and
it's
just
it's
no
longer
really
the
track
ID.
But
why
doesn't
the
track
ID
just
change
to
be
what
you're
going
to
put
in
the
remote
track?
Id
like
that's
how
it
worked
before
so
why?
Why
do
we
need
to
change
it?
So
it
works
differently
because.
C
Before
the
track
was
actually
created,
when
you
applied
the
description,
so
it
can
be
created,
you
know
from
with
that
ID
provided,
but
now
the
track
car
exists,
so
you'd
have
to
be
changing
its
ID
after
creation
and
that's
likely
to
mess
up
other
algorithm
algorithms
that
you
know
rely
on
MediaStream
track.
Ids
there
has
to
mr.
tribe
IDs
remain
constant.
D
D
D
They
were
the
ID
of
the
sender
and
if
the
sender
changed
its
ID
due
to
changing
whichever
tracks
got,
mapped
onto
it
and
stuff,
I
read
the
specs
previously
as
saying
that
that
would
get
reflected
over
to
the
other
side,
and
it
would
change
well,
obviously,
I'm
not
fixed
that
behavior,
but
I'm.
Just
saying
that's
how
I
interpreted.
D
C
D
D
A
D
D
E
D
C
The
point
of
having
a
track
at
offer
time
is
that
I
can
hook
up
this
track
to
a
renderer,
and
you
know
be
assured
that
it
will
play
media
as
soon
as
it's
receive,
even
if
it's
before
the
answer.
So
if
we
say
when
you
get
an
answer,
actually
we
create
a
new
track
that
defeats
purpose,
because
what
would
that
old
track
even
be
used
for
then
right.
D
Right,
you
have
had
to
create
it
with
the
correct
name
if
you
want
it
to
be
hooked
up
so
I
get
your
point.
This,
like
this
sort
of,
seems
like
a
not
big
deal
change
I.
Do
wonder
if
we
should
just
move
if
the
track
IDs
are
a
unique
thing.
We
use
to
keep
track
of
track
IDs.
Why
they're
the
same
as
the
app
data
and
the
sdp
I
did
I,
don't
really
know.
C
D
E
D
E
D
G
A
I
think
doesn't
really
matter
in
which
just
appealed
its
transfer
goes
to
the
other
side,
I
mean
if
we,
the
whole
idea
here
is
to
allow
people
to
kind
of
kind
of
synchronize
which
track
is
used
in
which
way
on
both
sides
of
the
peer
connection.
So
we
happen
to
use
the
update
a
feeling,
I
study
for
it
that
irrelevant
in
this
case,
okay,.
D
D
A
That
the
real
confusion
is
that
the
the
API
has
evolved
so
much
over
time.
I
mean
it
used
to
be
like
you
always
get
a
new
track,
and
then
you
have.
We
have
these
centers,
that's
kind
of
like
a
like
a
pipe
four
and
then
you
can
replace
the
track
inside
of
it.
So
suddenly
the
tracks
on
the
receiver
receiving
site
is
not
the
track
it
used
to
be
so
I
mean
that's
the
whole
eye.
Confusion
with
IDs,
in
this
case
the.
B
B
H
There's
we're
going
to
break
people
here.
This
is
because
we
have
transceivers
is
a
paradigm
shift
where
you
don't
add
track
on
one
end
and
they
appear
on
the
other
tracks
are
now
the
remote
track
are
attached
to
the
sender,
so
it's
a
totally
different
model
as
far
as
lifetime
track.
So
when
you
negotiate
a
sender
track,
you
don't
end,
we
don't
end
remote
tracks
anymore.
We
just
mute
them.
So
definitely
I
think,
would
be
a
prudent
with
some
help
for
people
to
the
gerak.
This
change,
given
that
we.
E
H
Implementations
in
all
browsers
now
almost
and
none
of
them
work
this
way.
So
my
only
comment
on
and
I
think
remote
track
kind
of
exists,
because
there
is
a
way
to
basically
work
around
by
look
by
parsing,
the
STP,
remotely
and
figuring
out
this
STP
track
for
people
who
really
don't
want
to
use
mid-and
or
have
some
reason
to
do
it.
The
old
way,
so
in
that
sense,
I
think
remote
track.
Id
is
the
best
solution.
The
only
solution
that
might
be
better
would
be.
H
If
there
was
excuse
me
if
there
was
any
kind
of
ceiling
media
capture
for
allowing
us
to
change
the
track,
ID
itself
and
if
that's
or
if
that's
uglier,
this
is
ugly
either
way.
But
it's
a
bit
of
a
remote
track.
Id
feels
like
a
bit
of
a
band-aid
solution,
but
it
might
I
guess
it
might
still
be
better
than
having
mutable
media
stream
track.
Ids.
A
H
C
F
A
D
C
The
only
reason
this
is
added
basically
is
for
backwards.
Compatibility
for
applications
that
you
know
are
built
around
track
IDs
and
want
to
keep
using
track
IDs.
But
you
know
we
shouldn't
worry
about
McGee
at
work
or
replace
track
and
everything
because
you
know
people
using
the
transceiver
API
should
be
using
them
in
or
other
information
to
associate
me.
But.
F
D
H
I
But
I
think
the
point
is
I.
Think
the
point
here
is
that,
instead
of
considering
this
legacy
support,
we
could
actually
consider
it
a
simple
API
support
so
that
essentially
we
support
two
models.
We
support
a
track
model
and
we
support
the
transceiver
model.
But
the
track
model
has
limits
right
and
just
say
you
can
use
the
track
model
as
long
as
you
don't
care
about
early
media
or
using
replace
track
as
long
as.
F
D
If
we're
going
to
have
a
way
to
make
this
work,
it
should
work
in
all
the
cases,
and
all
we
have
to
do
is
do
set
a
sender,
a
setter
on
the
other
side
and
you're
right.
That
will
cause
a
renegotiation,
but
we
have
terms
of
things
that
cause
a
renegotiation
and
the
close.
Oh,
no,
we
just
set
the
flag
renegotiation
needed
in
the
spec
and
in
the
code,
you
don't
really
add.
You
already
have
code
to
deal
with
that
event.
So
wait
so
you're
saying
you
got
that
happen.
D
C
Saying
you
would
set
an
attribute
on
the
sender
side,
it
would
cause
on
negotiation
needed.
It
would
cause
you
to
create
a
new
offer.
With
this.
You
know
one
feel
different.
You
signal
that
offer
to
the
other
side
now
TD,
the
feel
is
different.
That
seems
like
way
more
effort
than
you
need
to
do
when
you
can
just
signal
that
you
know
send
a
signal,
a
message
independently
yeah.
D
C
This
is
doing
is
providing
an
accessor
for
something
that's
already
in
STP.
You
know
as
a
little
convenience,
so
I
don't
think
it's
that
you
know
we're.
You
know
introducing
whole
new
model
here
and
we
either
have
to
you,
know
completely
and
make
sure
works
completely
or
not
at
all,
and
we
already
have
a
truck
track
model
we're
trying
to
support
you
know
without
a
track.
This
is
just
how
a
little
band-aid
I
support.
You
know
convenience
for
people
who
still
care
about
that
track.
Id
fitting
STP,
that's
now
being
ignored.
Okay,.
D
C
H
B
H
Removing
a
remote
truck
idea:
well,
it's
not
in
yet,
but
not
having
our
mo
track.
Id
does
not
remove
the
need
to
understand
what's
going
on
for
implementers.
This
is,
if
anything
this
is
what
I
like
about
this
is
that
it
gives
us
at
least
a
place
in
the
spec
to
talk
about
this
wort,
and
it
is
a
wort
whether
we
have
it
visible
in
the
spec
or
not.
D
Well,
I'm,
suggesting
that
the
STP
doesn't
require
this
data
to
be
on
the
field
at
all
and
purposes,
saying
that
if
what
we're
telling
people
is
you've
got
to
change
your
code,
we
broke
this
old
track,
ID
thing
again,
use
it
anymore
and
so
figure
out
how
to
use
some
other
separate
signaling
information
to
make
this
work
and
track.
Ids
are
not
put
in
the
SDP
at
all,
they're
not
sent
in
it,
and
they
are
unique
to
your
side.
There's
no
coordination
of
track
IDs
using
SDP
between
the
two
sides,
not
coordinated
to
do
it.
D
C
D
F
H
Let
me
add
one
thing
that
I
think
it
is
possible
to
use
for
an
app
to
use
or
place
track
as
long
as
they
keep
track
of
the
original,
ID
and
they'd
have
to
just
understand
and
correlate
and
keep
the
tracks
that
were
replaced
and
correlate
the
original
track
instead,
so
it
just
doable
it's
ugly
about
it.
People
want
to
do
it
that
way.
F
F
F
H
E
H
All
right,
the
good,
the
good
news
is
that
a
surprise,
I
understand,
media
stream
IDs
can
still
be
preserved
because
they
don't
become
public
to
JavaScript
until
the
track
event,
fires.
So
right
for
people
who
have
only
one
audio
track
and
one
video
track
in
their
streams,
they
could
car
light
that
way.
So
this
will
don't
be
a
problem
for
once
you
start
adding
multiple
tracks
of
a
kind.
C
C
H
H
C
A
D
D
D
I
I
think
my
preference
right
now,
having
sort
of
heard
this
conversation
would
be
add
the
SDP
access
called
get.
You
know,
get
app
data
or
something
as
as
Taylor
just
described,
but
also
at
a
set
app
data
on
the
sender
side,
so
that
you
can
an
application
can
deal
with
all
the
hard
cases
if
it
wants
to.
A
I
Yeah,
but
doesn't
the
track
model
means
I
mean
you
know,
I'm,
not
suggesting
we
go
this
route,
but
we
could
even
add
you
know
you
add
something
on
replace
track.
That's
optional!
If
somebody
actually
provides
an
ID,
a
track
ID,
then
what
you're
saying
is:
do
negotiation,
which
kind
of
defeats
the
purpose
of
replaced
track
for
99%
of
the
people
who
use
replace
track
but
I'm
just
saying
conceptually,
you
can
get
that
effect
by
leaving
replace
track
the
way
it
is
and
and
doing.
H
H
D
I
understand
that
argument,
but
I
think
if
you
want
to
go
down
that
argument,
my
suggestion
is:
we
do
not
write
any
track.
Id
yes
compete
nor
receive
it
and
we
get
rid
of
all
of
it.
We
just
use
a
monkey.
I
mean
the
the
track.
Id
had
a
specific
sort
of
use
case
that
people
imagine
how
use
it
and
you
listen
at
the
end
points
out.
You
can
use
it
that
way.
I!
D
Don't
think
that
adding
a
setter
of
this
data
I'm
not
saying
and
yes,
it
would
cause
renegotiation,
but
generally
anytime
you're
you
want.
If
you
wanted
that
to
happen,
your
application.
It
means
you
want
to
do
a
round
trip
of
messaging
anyway,
so
you
know
people
who
want
to
use
that
it's
a
very
easy
way
for
them
to
use
it.
If
they're
using
that
model,
people
who
don't
want
to
use
it
can
use
them
ID
and
then
what
they
will
never
use
any
of
it
on
either
side
right,
but
it's
at
least
complete.
D
F
C
Only
add
this
because
it
was
extremely
cheap.
You
know
it's
just
an
access
it
for
something
SDP,
I
don't
want
to
go.
You
know
down
the
route
of
your
adding
eight
guys
to
make
you
know
and
sure
someone
can
you
know
use
track.
Ids
everywhere,
I
been
if
they're
easier
placed
track.
None
of
the
things
that's
sees
a
scope,
Oh.
D
I
mean
if
they're
on
tell
I
mean
I'm,
not
imagining
this,
be.
You
know
about
the
same
amount
of
text
on
this
inner
size
we
serve
as
I.
Just
like
you
know,
look
when
this
is
set.
It
sets
the
value
that's
put
in
the
next
offer
answer
cycle,
and
you
know
that's
the
renegotiation
needed
slack.
Well,
I!
Don't
care
if
it's
that's
the
renegotiation
black,
not
effective,
youth.
That
now
to
know.
E
C
H
A
F
C
D
I
Little
a
question:
jana
VAR,
you
made
the
comment
that
dead,
mid
wasn't
really
properly
supported.
Well,.
B
H
B
C
There's
so
one
question
for
the
last
issue,
so
it
shouldn't
take
that
long.
Okay,
so
currently
the
only
time
where
the
msid
AppData
field
actually
is
the
track.
Id
is
when
you're
saying
a
remote
description
that
has
a
new
M
section
with
a
track,
which
is,
you
know,
probably
not
a
very
common
situation.
You
know
if
you're
just
you
know
sending
attract
you
by
direction
way
between
two
peer
connections
and
both
of
them
ended
up
with
generate
IDs.
So
my
question
is:
should
we
you
know
just
remove
this
case
of
the
track?
C
C
H
F
D
Course,
of
course,
but
just
that
the
app
data
goes
on
after
it,
so
we
which
is
optional.
We
we
update
the
various
effects
just
to
basically
be
like
we
no
longer
have
to
worry
about
one
more
identifier
in
the
STP
data,
which
no
one
knows
what
we
do
with
it,
because
there's
already
not
enough
confusing
identifiers
in
it.
A
C
F
C
Okay,
this
is
a
very
related
issue
that,
due
to
the
paradigm
shift
of
the
transceiver
model,
we
stopped
having
visible
effects
of
remove
track
being
called
essentially
remove
track.
Just
stops
the
sender
from
sending
anything
and
it
changes
them
section
direction
if
it
was
you
send
receive
to
receive
only,
but
aside
from
that,
there
weren't
as
many
visible
changes.
So
you
know
you
have
to
I'll
check
the
direction
attribute
after
every
sever
modus
ssin.
If
you
wanted
to
see
if
this
happened
so
after
PR
1
for
2
now
there
are
some
visible
changes.
C
If
the
track
is
part
of
any
streams,
it
will
be
removed
and
it'll
be
muted,
and
then
you
know
if
it's
that
the
transceiver
direction
changes
back
then
you
know
the
track
event.
Will
fire
again
it'll
be
added
to
the
stream
again
I'll
be
on?
You
is,
but
it
won't
be
ended,
because
there
still
is
that
possibility
that
the
sender
will
start
sending
again
and
the
other
receivers
track
needs
to
start
receiving
media
again.
C
B
B
C
B
B
C
C
The
problem
with
this
is
that
that
means
that
every
new
offer
answer
you
do
is
the
coke
you've
selected
before
goes
away,
and
you
have
to
call
set
parameters
again,
and
you
know
possibly,
this
would
create
some
churn
and
in
the
implementation,
as
its
you
know,
trying
to
release
and
reserve
hardware
resources
or
whatever
or
causing
a
you
know,
frame
to
leak
out
with
the
codec
from
the
remote
description
before
set
parameters
has
a
chance
to
be
followed.
C
That
sort
of
thing
so,
when
posing
doing
in
this
PR
one
592,
is
instead
of
having
the
the
code
be
selected
by
reordering
the
list.
You
just
set
a
codec
payload
type
field
in
the
encoding
parameters
that
references
one
of
the
codecs
from
the
list,
which
is
how
it
works
into
RTC
and
the
simplified
same
things.
It
means
that
we
can
say
that
as
long
as
a
subsequent
remote
description
still
has
that
that
payload
type
you
know
the
payload
type
field
can
stay
the
same,
and
you
can
just
continue
the
sending
with
that
codec.
C
C
So,
basically,
you
know
our
set
parameters
doesn't
need
to
support
completely
removing
codecs,
because
there's
another
way
to
do
that.
So
now
that
you
know
the
only
thing
Sopranos
needs
allow
use
is
select.
The
sense
codec,
Lakota,
kala
type
approach
seems
like
I,
said
their
way
to
do
that,
and
one
more
thing
to
note
is
that
I
put
this
on
our
speed
coding.
Perimeters
in
the
PR
which
matches
our
TC,
but
that
means
that
it
would
now
be
possible
to
select
different
codecs
for
encoding.
C
C
D
D
D
C
D
Over
that
I
can
live
with
that
I'm,
not
in
favor
of
having
that
API
at
all,
but
never
mind
that,
like
how
do
I.
So
what
API
do
I
use
if
I
don't
want
to
do
that,
but
I
want
to
have
the
API
that
says:
I
will
honor
the
SDP
as
it's
supposed
to
be
done
right,
but
I
won't.
Do
this.
One
codec
like
either
saying
there's
a
different
API
that
I
use
to
control
that
up.
C
D
C
D
C
D
C
D
D
C
D
C
But
my
recollection
is
that
the
reason
we
went
would
be
you
have
to
set
it
every
time
is
because
we
wanted
to
make
what
you
were
saying
earlier
happened
where,
when
you
call
set
remote
description,
it
does
what
remote
description
said
and
also
because
we
didn't
want
to
open
the
can
of
worms
of
you
know.
I,
do
this
reordering
an
hour!
No
description
adds
some
I
can
remove
some
codecs,
how
you
intersect.
You
know
the
new
list,
with
my
reordered
list
run.
We
said,
okay,
that
that
seems
really
complicated.
C
Let's
just
say
it
gets
blown
right
every
time,
but
now,
if
we,
if
it's
a
simpler
API,
we
don't
have
that
problem
in
it
at
the
time
that
we
added
set
parameters
with
codecs.
We
didn't
have
the
codec
preferences
on
the
transceiver,
and
now
that
we
have
the
critics
preferences
on
the
receiver,
we
can
have
a
more
simple
version
of
the
product
choice
and
set
parameters
which
I
think
that's
what
neighbors
proposing
here's
more
simple
version,
so
I'm
a
favor
of
it
yeah.
B
C
Okay,
this
probably
will
we'll
spend
the
remainder
of
the
discussion
on
when
I
import
and
details
transports
or
you
know,
objects
get
created.
The
first
question
is:
do
you
get
a
new
RTC
I
transport
object
on
ice,
restart
and
I
thought
about
this?
A
lot
and,
in
summary,
I,
don't
see
any
advantages
to
having
a
new
object
and
I
see
that
the
good
it
introduced
some
complexities
either.
We
need
to
have
DTLS
transport
ice
transport
attribute
become
a
list
so
that
you
can
inspect
both
the
old
and
the
new
ice
transport.
C
And
you
know
the
rest
of
the
spec
is
written
around
some
chain
that
there
will
be
one
object,
so
it
requires
two
changes
elsewhere
and
I.
Don't
really
see
that
having
one
object
hurts
us,
because
you
can
still
see
both
the
new
and
old
candidates
by
calling
get
local
candidates.
You
can
see
whether
the
current
can
appear
is
from
the
previous
ice
generation
new
generation.
C
By
inspecting
the
active
candidate,
fair
attribute,
you
knows,
I
say:
will
change
from
you've
connected
back
to
checking
or
I
get
to
go
from
completed,
to
connect
it
and
eventually
complete
it
again.
So
you
know
I
feel
like
all
the
information
that
an
application
when
we
can
be
communicated
with
one
object
and
I
mean
two
objects,
doesn't
really
buy
us
anything.
It's
not
just
to
its
in
mobile
yeah
I
mean
objects
or
restart.
B
C
E
Yes,
I'm
on
the
call,
but
WebEx
has
been
giving
me
trouble.
I
mean
I
still
think
this
a
lot
but
I'm
going
to
defer
to
the
Consensus.
C
B
C
B
C
Now
this
is
similar
question,
but
for
DTLS
training,
sports
I
guess
begin.
This
issue
specifically
talks
about
when
a
local
offer
initiates
a
nice
restart
and
then
the
remote
endpoint
decides
to
also
have
a
new
DTLS
association,
but
I
think
we
can
there's
also
the
situation
where
a
remote
offer
initiates
a
new
gos
association,
so
I
think.
First,
we
change
the
general
question
of
should
new
DTLS
associations
result
in
new
TC,
LS
transport
objects
or
not,
and
I
guess
similar
to
the
reasoning
on
the
last
slide.
C
I,
don't
see
that
having
multiple
objects
would
provide
the
application
with
anything
new
and
it
would
create
more
complexity.
Since
now
you
have
to
manage
multiple
objects
and
you
know
see
if
the
object
changed
and
maybe
I
need
to
hook
up
a
new
state
change
event
handler,
as
mentioned
here
so
again,
I
think
it
would
be
simpler
if
he
has
an
existing
DTLS
transfer
object.
You
know,
has
the
set
of
remote
fingerprints
or
remote
certificates
change.
C
When
you
set
the
description-
and
you
know
the
kids
state
would
go
from
connected
back
to
connecting,
for
example,
but
you
still
have
one
object.
I
was
sort
of
on
the
fence
about
this,
because
it,
you
know
sort
of
makes
more
sense.
Intuitively
the
new
GCLs
association
would
result
in
new
object,
but
you
know
when
I
started
thinking
about
the
practical
implications.
I,
don't
think
that
actually
buys
us
anything.
B
C
I
think
this
one
could
be
a
little
more
manageable,
but
I
agree
with
with
Taylor's
assessment
that
it
doesn't
really
buy
the
application
developer.
Anything
to
have
multiple
objects
and
implementing
it
to
look
like
one
object
is
easy,
so
there's
really
no
advantage
to
having
it
be
a
separate
object,
and
it's
just
a
little
bit
just
additional
complexity.
C
Okay,
I
sort
want
to
talk
about
this
here,
because
I
thought
would
be
a
good
opportunity
to,
but
it
mostly
concerns
IETF
standards.
So
I'm
not
sure
you
need
to
get
some
some
tracks
on
the
our
TC
webmail
and
list.
But
let
me
just
may
summarize
this
you
and
then
we
can
decide
what
to
do
so.
C
Basically,
there
are
some
issues
with
a
bundle
used
with
ice
and
specifically
triple
eyes
where
it
may
be
ambiguous.
If
an
MSHA
section
is
rejected,
you
know
what
the
endpoints
are
supposed
to
do,
as
fallback
like
whether
they
should
use
an
existing
eye
session
or
use
a
new
one,
because
the
the
bundle
spec
is
written,
largely
largely
around
the
concepts
of
there
being
unique
and
shared
addresses.
But
you
know
for
ice
where
the
address
is
something
that
can
change
and
where,
if
one
hasn't
been
selected,
yet
it
will
just
be
empty.
C
C
So
current
implementations,
at
least
common
Firefox,
follow
a
policy
of
the
ice
transport
Falls
end
section,
meaning
you
know
if
I
create
an
offer
with
an
audio
and
video
section,
I
start
with
an
audio
ice
transporting
a
video
ice
transport
if
I,
negotiate
bundling
and
things
start
being
bundled
on
audio
transports.
Now
the
audio
M
section
gets
rejected.
That's
a
problem
because
sort
of
you
know
that
that
likes
transporters
attached
to
that
M
section.
C
C
Like
on
the
same
side
of
the
negotiation
mean
in
the
initial
offer,
you
have
a
1u
frag
pass
the
combination
for
the
audio
I'm
section
and
one
for
the
video
M
section,
and
then
you
can
reliably
or
unambiguously
signal
which
ice
session
you
want
to
be
used
as
fallback,
because
you
know
do
you.
Frags
are
unique
and
if
it's
the
same,
you
frogenstein
session
means
use
the
existing
session.
C
C
B
C
C
D
Be
added
to
ask
a
question
here
on
this:
one
I,
like
everything,
you're
saying,
makes
sense.
I'm
just
wondering
about
the
case.
Remember
ice
is
already
widely
used,
so
if
you
had
to
in
lines
with
two
different
ice
sessions-
and
they
have
their
you
frags
for
each
one
of
them-
you're
not
even
doing
bundle.
Okay,
just
two
in
lines,
two
different
night
sessions,
and
then
you
swapped,
the
you
swap
those
two
life
sessions.
Okay,
you
just
saw
on
the
next
offer
answer.
D
C
Do
that
right?
No,
no,
that
would
be
interpret
is
a
nice
restart
for
both
time
sections.
It's
only
with
the
bundle
spec.
Where
now
you
know,
nm
section,
maybe
using
a
transport
that's
described
in
some
other
M
section.
Where
is
it
an
issue
where
you
need
some
way
to
actually
identify
the
transport?
Or
previously?
You
know
the
EM
section
index
was
the
sign.
You
know
that
identifier
or
you
can
read
you
need
one,
because
you
can
just
rely
on
things
being
matched
by
them.
Section
index.
D
C
D
C
E
Are
you
trying
to
the
stingy
to
cases
I'm
trying
to
get
between
them?
There's
the
case
where
you
do
offer
opens
with
two
M
sections
that
are
bundled
and
the
first
one
is
rejected
the
case
we
are
you
negotiate
and
then
you
renegotiate,
you
drop
one.
Are
you
saying
even
the
first
case
isn't
work
properly?
Are
you
saying
the
only
sex
customer
problem.
C
E
E
C
C
D
I
think
we
need
to
look
at
the
you
frag
much
deeper
to
understand
whether
it
actually
works
with
understand
what
workers
with
the
oppose
all
new
stuff.
But
if
it
works
in
a
backwards,
compatible
ways
is
not
clear
to
me:
it
works
and
that
may
just
be
I,
don't
understand
the
problem.
Well
enough.
I
got
no
objection
to
it
if
it
works,
but
I'm
not
at
all
convinced
yet,
okay,
how
many
cases
are
there
where
we
actually
have
like
an
old
client
using
bundle?
No,
and
in
you
know
it
can't
be.
D
C
D
No
I
was
worried
more
about
us
redefining
how
ice
works,
because
that
way,
you
know
I,
don't
what
I
don't
want
to
go
say:
hey
here's,
an
easy
solution
for
us,
that'll
work
great!
Then
we
go
to
the
music
working
group
change
ice
to
work
like
that
and
realize
that
that's
a
backwards,
compatible
change
with
how
ice
works
and
that
we
end
up.
You
know
having
the
same
discussion
nine
months
from
now.
Okay,.
C
B
B
A
B
A
I
was
just
cutting
our
solution
for
the
last
one,
so
okay
yeah,
so
that
what
we
currently
have
in
this
bag
is
that
we
have
a
bunch
of
validation,
set
parameters
and
the
the
all
the
checks
that
we
have
can
be
done
synchronously,
but
the
the
method
is
promise
based
to
kind
of
support
future
errors.
That
cannot
be
checked
on
the
on
the
main
thread,
so
so
I
said
a
question
on
the
mailing
list.
A
Asking
what
kind
of
errors
would
be
see
that
that
the
media
back
end
would
report,
and
then
I've
got
some
some
hints
from
Taylor
and
all
about
some
old
issues
where
this
was
discussed,
and
there
was
a
problem
when
someone
when
the
developer
removes
all
the
code
makes
accept
a
heart
of
bear
a
codec
that
depends
on
hardware.
So
the
best
efforts
thing
won't
work
really,
because
there's
no
software
to
to
choose
from
so
well
what's
in
PL
5060
right
now
is
is
a.
A
Apart
from
the
synchronous
argument,
check,
there's
a
their
support
where
you
in
parallel
configure
the
media,
stack
to
use
parameters
for
for
particular
sender
and
then
there's
a
section
where
the
media
stack.
You
can't
report
back
errors
of
of
different
kinds,
and
only
one
currently
specified
is
hardware
encoder
error.
So
this
is
a
RTC
or
DC
error,
so
one
when
we
have
this
in
place,
so
we
have
at
least
one
type
of
error
that
is
synchronous,
then
at
it's
motivated
to
have
this
as
a
promise
based
method
and
we
can
add
more
errors.
A
B
I
guess
we,
the
main
purpose
of
having
this
slide
in
here,
is
just
to
check
that
the
model
that
we're
using
still
makes
sense
and
because
we
just
had
the
discussion
about
it
relating
to
other
issues,
the
idea
is
you'll
check,
set
parameters
and-
and
maybe
you
know,
check
resources
or
whatever
you'll
figure
out
that
there
was
an
error,
but
the
model
we're
using.
Is
that
there's
not
some
error?
B
That's
going
to
happen
like
ten
minutes
from
now
right,
so
because,
right
now,
the
send
and
receiver
have
no
generic
async
error,
handling,
there's
no
on
error
event
handler
or
anything
like
that,
and
once
you've
accepted
these
parameters.
You
know
you've
executed,
set
parameters.
It's
not
like
something's
going
to
happen
like
somehow
the
hardware
resources
run
out
or
something
our
assumption
is
somehow
you
cope
with
that
and
you're
not
going
to
have
an
error
like
later.
B
B
B
You
know
if
you
were
to
try
to
do
that
exactly
it's.
Obviously,
you
can't
scale
to
71
point
one
one
one
times.
Fifty
three
point,
three,
three:
three,
that's
the
fun
okay,
you
can
also
have
other
inputs
where
you
know
other
examples
of
this.
We
use
scale
resolution
down
by
red
too,
and
you
have
some
fractional
pixels
all
right.
B
So
the
question
is
what
you,
what
you
do
here
and
previously
I
should
mention
we,
unless
you
have
some
illegal
value
of
scale
resolution
down
by
we
do
we
never
create
an
error,
so
none
of
these
cases
would
ever
generate
an
error
and
then
the
question
is
what
what
do
you
try
to
do?
And
this
is
PR
1577,
which
basically
says
round
up
to
the
nearest
integer.
D
E
D
J
H
H
B
F
C
D
F
D
Have
to
you
know,
interpolate
data
or
something
because
I
give
you
a
bilinear
interpolation
to
go
down
from
you
know.
By
to
that
last
scan
line
is
going
to
have
to
be
copied
or
somehow
interpolated,
but
if
you
just
crop
it
off
before
you
you
round
down
like
you
do
a
floor,
then
it's
much
much
simpler.
F
H
D
F
D
C
F
J
B
B
F
H
E
F
F
J
F
D
F
J
J
Wouldn't
deviate
much
I
would
basically
do
the
do
the
division,
and
you
know
round
round
the
pixels
as
needed
as
per
the
previous
discussion
and
then
yeah
and
then
and
then
and
then
and
then
ship
it
and
the
fact
that
the
if
the
aspect
ratio
is
slightly
off
due
to
the
rounding
or
whatever
you
know.
Oh
well,.
D
Right,
so,
to
paraphrase
what
you're
saying
Randall,
if
we're
scaled
down
by
X,
we
divide
the
width
by
X.
We
divide
the
height
by
X.
We
take
the
floor
of
both
of
those,
and
the
aspect.
Ratio
is
what
the
aspect
ratio
is
when
we're
done
that
that,
yes,
right
so
I,
don't
think
there's
any
within
reason.
Here,
it's
just
the
aspect
change
the
aspect
can
change
slightly
due
to
the
way
we
do
the
round
deck
yeah.
D
Yeah
yes,
I,
agree,
adjacent
Roy
does
wouldn't
contradict
this.
You
know,
Jason
Roy's
talks
about
fitting
image
adder,
and
this
is
not
fitting
image
adder.
This
is
an
entirely
different
thing
and.
D
F
D
If
you're
outside
what
the
image
ad
are
specified,
then
you
don't
send
it,
but
that's
a
totally
separate
issue.
I
mean
the
one
thing
we
haven't
talked
about
at
all
and
its
really
impressed
even
a
more
important
situation
is
the
case
where
the
encoder
needs
to
ramp
down
the
resolution,
encoding,
the
meat
sandwich
limitations
and
that's
all
going
to
happen
internal
to
the
implementation.
D
It
Jason
talks
about
this
a
little
bit,
but
just
like
as
an
aside-
and
you
know,
it
just
hat-
needs
to
make
sure
that
whatever
it's
doing
is
consistent
with
whatever's
been
expressed
by
the
remote
side
in
terms
of
the
minimum
resolution.
But
you
know
the
same
sort
of
thing:
it's
trying
to
preserve
aspect
ratio
to
the
extent
that
it
can
and
that's
the
spirit
here
and
I-
think
that
conclusion
make
sense.
So.
B
All
right,
so
this
was
a
question
that
came
from
Colin
as
to
how
to
discover
what
algorithm
identifier
values
the
browser
supports.
So
in
PR
1553
we
have
our
proposal
for
this,
which
is
to
add
a
get
supported,
algorithms
method,
which
returns
a
sequence
of
at
least
one
supported,
algorithm
and
I
guess.
The
question
for
the
group
is:
is
this
something
people
will
implement
and
is
there
consensus
to
add
this
to
the
spec
to
solve
the
problem?
Colon
brought
up.
C
I
thought
we
discussed
this
to
the
previous
virtual
interim,
and
the
issue
was
that
an
algorithm
identifier
is
how
a
trainer
tries
thing
and
the
browser
may
support.
You
know
essentially
an
infant.
You
know,
combination,
number
of
combinations
of
parameters.
So
what
right?
Well
with
this
return,
I'm
going
to
have
to
return
some
representative
subset
and
how
we
define
that
it's.
E
D
E
C
E
D
B
B
E
I,
don't
object,
I
would
point
out.
Martin
Thompson
is
on
pto.
He
may
make
a
fuss
when
he
gets
back,
but
my
sense
is
using
the
rough
on
this
one.
Okay,.