►
From YouTube: WebRTC WG meeting 2022-07-19
Description
Meeting minutes at https://www.w3.org/2022/07/19-webrtc-minutes.html
02:24 WebRTC Extensions
02:40 Add SCTP rate control params to RTCPeerConnection constructor
12:15 Issue 107: maxFramerate probably should not be allowed in addTransceiver/setParameters for audio senders
12:54 Issue 110: getDataChannels() method on RTCPeerConnection
17:32 WebRTC
17:50 Issue 2735: webrtc-pc specifies using ‘~’ in a=simulcast, but does not support RFC 7728 (RTP pause)
25:36 #2746: Enum RTCIceCredentialType with only one value
29:33 Issue #2743: SLD/SRD (answer) trips over itself when narrowing simulcast envelope
33:50 #2751 Intended outcome when modifying direction in have-local-offer
37:34 WebRTC Simulcast issues
38:35 Issue #2722: sRD(offer) completely overwrites pre-existing transceiver.[[Sender]].[[SendEncodings]]
42:02 Issue #2724: The language around setting a description appears to prohibit renegotiation of RIDs
1:07:31 #2722
1:11:55 Issue #2723: The prose around "simulcast envelope" falsely implies that simulcast encodings can never be removed
1:31:03 TPAC
B
And
today
we're
going
to
cover
webrtc
extensions
in
order
to
see
pc.
We
will
not
be
having
an
august
meeting.
The
next
meeting
will
be
the
tpac
meetings
and
if
you
go
on
the
working
group,
wiki
site
you'll
see
what
we've
got
planned
there.
I
believe
we
have
two
webrtc
working
group
meetings
and
then
we
have
joint
meetings
with
the
media
working
group.
So
that's
the
schedule
for
september,
but
nothing
for
august.
B
C
B
B
The
meeting
is
being
recorded
if
you
want
to
get
into
the
queue
type
plus
q
and
minus
q
and
google
me
chat
to
get
in
and
out,
please
use
headphones
or
an
echo
canceling
speaker
phone
wait
for
the
microphone
access
to
be
granted
before
speaking
and
say
your
full
name,
although
at
this
point
with
so
few
people,
probably
we
can
recognize
your
voice
all
right.
A
little
bit
of
note
about
document
status,
just
because
something's
in
the
repo
doesn't
mean
it's
been
adopted.
B
We
have
a
call
for
adoption
for
that
and
the
editors
drafts
don't
necessarily
represent
consensus.
The
working
group
drafts
do,
and
sometimes
we
merge
pr's
with
that
black
consensus.
But
then
we
put
a
note
to
say
that
they
don't
okay.
So
here's
what's
on
the
agenda.
We're
gonna
spend
some
time
on
a
few
webrtc
extensions
issues
and
then
talk
about
simulcast
issues
in
webrtc,
pc
and
hopefully
we'll
get
through
in
two
hours
and
hopefully
maybe
even
before.
B
B
B
And
the
thing
is
rto
max
min
and
initial
their
properties
of
the
sctp
connection,
they're,
not
per
data
channel,
and
so
you
can't
set
that
on
a
purchase
channel
basis.
They're
the
recommended
values
are
in
rfc
4960,
section
15.,
and
the
problem
here
is
whether
we
can
allow
these
values
to
be
set
on
the
programmatic
control.
B
And
the
traditional
answer
to
that
is:
is
they
require
a
lot
of
study,
for
example
in
tcp?
They
changed
some
of
these
things
in
rfc
6298,
but
they
had
to
go
through
a
whole
process
to
simulate
what
the
effect
would
be
and
leaving
that
to
the
developer
could
be
really
problematic.
You
could
see
that
they
could
set
all
kinds
of
weird
stuff,
and
the
other
problem
is
that
in
apps
that
do
this.
For
example,
I'm
familiar
with
like
cloud
pc
apps.
B
D
C
D
D
D
I
don't
think
we
have
a
good
api
and
I
also
don't
think
we
have
a
good
like
alternate
settings,
so
I
think
that's
I
think,
saying
making
these
properties.
I
think
what
I'm
trying
to
say
is
making
these
properties
public
would
be
a
mistake,
but
having
some
kind
of
low,
latency,
config
or
you
know,
failed
faster
config,
because
what
we're
talking
about
here
is
actually
how
fast
we
want
it
to
fail.
If
it's
over
congested.
D
D
B
B
E
So
I
I,
since
we're
so
few
people
I
put
myself
on
the
queue,
but
just
a
question
about
what
would
this
low
latency
mode
look
like
I
mean
if,
if
you
just
need
to
time
out
faster,
the
javascript
could
could
just
time
out
after
whatever
number
it
wants
right.
It
could
do
a
set
timeout
15
seconds,
and
I
haven't
heard
anything.
I'm
gonna
assume
it
failed
right.
E
D
A
It
might
be
orthogonal,
but
it
might
also
be
related
if
you
want
to
know
whether
your
terminal
has
successfully
sent
a
comment,
you
can
just
wait
for
a
timeout
or
manual
in
your
application.
Wait
for
an
application,
control
message
or
just
something
on
the
stack
telling
you
yes,
message
has
been,
has
been
delivered
and
then
you
can
retry
on
your
own
and
you
don't
need
to
have
all
those
parameters.
Maybe
that's
something
also
to
consider.
B
B
A
One
issue
is
that
you
can
create
as
many
channels
and
close
them,
and
eventually
you
might
run
into
an
issue
that
you
have
to
many
of
us.
If
you
have
an
unbounded
list,
that
might
be
a
problem
to
keep
track
of
all
the
objects
forever
in
the
connection,
so
keeping
on
the
non-plus
channels
seem
to
be
an
interesting
property.
E
A
E
A
Sure
I
think
that
they
shouldn't
be
part
of
the
results
of
gay
data
channels.
If
you
keep
track
forever
of
all
the
closed
data
channels,
an
application
that
lives
for
a
very
long
time
may
have
an
unreasonable
number
of
data
channels
that
have
been
open
and
so
keeping
them
live
forever
might
be
an
issue.
D
E
E
E
A
A
A
D
A
E
A
E
A
C
So
so,
first
plus
one
on
removing
this,
given
that
there
is
no
momentum
toward
the
extension,
I
think
one
and,
depending
on
how
much
we
believe
this
extension
still
has
value,
one
way
would
be
to
remove
the
enum
from
pc
and
move
this
as
a
monkey
patch,
in
extension,
where
the
os
type
is
still
being
defined
or
simply
scrap
it.
If
we
don't
think
this
is
going
to
fly
anytime
soon,.
A
E
All
right
and
someone
added
a
slide
for
me
on
this
one.
So
thank
you.
I
was
thinking
about
adding
one,
but
this
actually
leads
up
nicely.
I
don't
think
this
one's
controversial,
but
it's
a
good
stopping
point
to
explain
some
a
few
things
that
could
be
useful
in
discussing
the
next
issue.
So
this
issue,
I
feel,
is
more
of
a
misunderstanding.
It's
it's
more
of
an
editorial
mistake.
E
Unfortunately-
and
I
think
this
was
a
mistake-
this
runs
a
file
of
some
other
language
we
have
where
we
were
trying
to
prevent
remote
offers
from
modifying,
send
encodings
beyond
the
initial
offer
right.
So
we
do
support
sfus
and
stuff,
sending
offers
that
can
offer
to
receive
things
simulcast
and
but
there's
a
problem
we
wanted
and
we
were
using.
This
send
encodings
internal
slot
to
say
well,
basically,
if
it's
been
set
already.
That
means
this
is
the
second
negotiation.
E
E
If
the
answer
doesn't
support,
simulcast
we've
allowed
it
to.
Basically
the
intent
was
that
we,
even
though
we
offer
simulcast
the
answer,
can
say
no,
I
don't
support
simulcast
or
or
I
support
simulcast
with
fewer
layers,
and
that
should
work.
So
we
should
fix
this
language
and
that,
hopefully,
is
not
controversial.
If,
if
it
is,
please
speak,
don't
speak
so
now,
otherwise
we
can
move
on
to
the
next
issue.
E
B
I
just
wanted
to
just
wanted
to
make
sure
we
got
the
one
the
resolution
to
this
in
the
notes,
so
we're
going
to
label
it
ready
for
pr,
and
I
think
actually
what
you've
just
said
young
ever
about
this
one.
I
think
it
feeds
into
some
other
ones,
and
hopefully
we
can
keep
that
in
our
brains
when
we
get
to
those
yeah.
E
So
to
hope,
sorry
I
was
if
I
was
confusing
things,
but
so
far,
we've
we've
talked
about
language.
That
would
affect
even
initial
negotiation,
because
you
can
do
pci
transceiver
before
you've
even
done
negotiation,
which
will
which
will
prime
the
send
encodings
internal
slot,
which
causes
that
side
to
be
very
rigid
about
not
changing
it,
which
could
lead
to
failures
that
we
weren't
intending
such
as
the
answer
coming
back
and
saying
yeah,
I
do
support
simulcast,
but
only
one
two
layers,
for
example.
B
E
Objections
to
that
so
from
here
on
we're
talking
about
renegotiations.
So
beyond
the
initial
negotiation,
where
everyone
agrees.
Oh
sorry,
there's
a
different
issue
in
the
middle
here.
My
apologies
so
hold
that
thought
for
another
issue,
and
here
we're
going
to
talk
about
something
else,
which
is
that
excuse
me.
We
added
a
change
to
the
spec
which
has
not
been
implemented
by
anyone,
which
is
that
if
you
get
a
set
remote
description
with
an
answer,
it
can
update
not
just
current
direction
but
also
direction.
E
In
hindsight,
we
think
this
was
a
mistake
because
it
creates
a
race
between
use
of
the
api
by
the
javascript,
for
instance,
to
set
tc
direction
directly
by
assigning
it.
A
value
like,
for
example,
inactive
or
send
receive,
send
only
receive
only
or
calling
pc
remove
track,
which
is
part
of
this
algorithm
is
to
set
the
direction.
E
However,
this
can
now
race
with
negotiation
or
renegotiation,
which
is
especially
annoying
if
you've
implemented
perfect
renegotiation,
where
the
whole
point
was
to
to
separate
renegotiation
from
the
rest
of
your
application
logic.
So
now
you
have
basically
erase
with
your
own
separation
layer
and
also
implementing
that
now
would
probably
break
web
compatibility,
so
the
proposal
is
to
revert
it
and
the
logic
for
this
is
that
we
think
we
got
it
wrong.
The
last
time
and
that's
stephan
hawkinson
was
actually
right
when
you
described
the
relationship
between
direction
and
current
direction.
C
E
Me
these
are
actually
separate
attributes
where
direction
reflects
this
side's
preference
in
offers
and
answers
it
generates,
whereas
current
direction
reflex
reflects
the
net
negotiated
direction
and
we
shouldn't
have
an
expectation
that
these
two
values
should
allow
sorry
about
the
dog.
Basically,
it's
normal
and
informative
for
them
to
differ,
and
it
keeps
negotiation
from
being
a
lossy
loop
where,
if
you
have
answers,
pin
narrow
offers,
but
bit
of
answers
can
also
narrow
subsequent
offers.
E
Then
you
end
up
with
a
what
I
call
the
negotiations
and
envelopes
gets
smaller
and
you
can't
undo
it
so,
for
example,
the
direction
of
send
receive
means
we
have
stuff
to
send
and
are
open
to
receiving,
and
the
current
direction
of
send
only
means.
The
other
side
has
nothing
to
send
at
the
moment,
but
that
may
change
in
future
negotiations.
E
B
B
What
we're
going
to
try
to
do
here
is
navigate
our
way.
I
think
we're
going
to
do
2724
first
yanivar,
because
that
seems
clear.
Hopefully,
if
people
get
confused,
we
can
try
to
show
you
some
of
the
text.
I'm
not
sure
that
would
necessarily
clear
things
up,
but
we're
going
to
try
to
get
into
this
ticket
and
hopefully
come
out
the
other
end
all
right.
Well,
actually,
we'll
start
with
2722.
B
I
guess
all
right,
so
this
one
is
about
that.
If
you
do
a
set
remote
description
on
an
offer,
you
completely
overwrite
pre-existing
transceiver
sending
coatings
and
the
basically
the
language
about
how
to
handle
some
acoustic.
Remote
offer
says
that
semi-coating
is
completely
replaced
based
on
the
ribs
in
the
simulcast
attribute,
and
that
works
fine
if
the
transceivers
aren't
yet
associated.
B
And
we
do
allow
a
set
remote
description
of
an
answer
to
remove
pre-existing
grids.
I
think
janivar
talked
about
that
already.
We
have
the
ability
to
basically
reject
summercast
in
part
or
totally,
and
we
probably
need
to
allow
set
remote
description
of
an
offer
to
also
remove
pre-existing
rids
as
well.
B
E
B
B
E
A
great
question:
it's
not
obvious
right,
so
we
do
seem
to
have
explicit
language
that
says
this
specification
does
not
allow
remotely
initiated
renegotiation.
That's
a
pretty
strong
statement
simultaneously.
The
spec
allows
answers
to
reject
simulcast
layers
in
at
least
initial
offers,
but
there's
also
together
this
means.
So
how
do
we
interpret
these
two
statements
together?
E
E
E
I
may
have
gotten
this
backwards
and
that
it
might
have
been
offered
to
receive
three
layers,
and
the
answer
is
to
only
send
two.
It
doesn't
matter
in
this
example,
so,
but
it's
more
likely
that
the
sfu
will
will
be
the
the
offer
right
and
then
it
can
say
I
can
receive
three
layers
and
the
client
says
no.
I
I'm
just
gonna
send
two.
E
E
If
webrtc
pc
is
going
to
mandate
that
we
you
know
this
has
been
fixed
now
we
can't
allow
any
remote
changes
to
that.
Does
that
mean
that
a
same
offer
answer
should
happen
again,
and
that
means
the
offer
should
send
three,
and
the
answer
should
receive
two
and
that's
okay.
Anything
else
should
fail,
or
does
it
mean
that?
No
because
the
first
negotiation,
the
result
was
a
narrowing
to
two
we're,
not
we're
not
going
to
reject
the
an
offer.
E
All
right,
I'm
not
hearing
anyone,
so
I
think
that's
good,
so
I've
already
put
a
checkbox
on
the
first
sentence
there,
which
should
a
subsequent
identical
offer
answer
succeed
because
the
net
result
is
the
same.
So
I'm
going
to
mark
that
say
yes,
so
we
have
some
other
questions.
What
if
the
answer
rejects
instead
of
rejecting
one
layer,
it
rejects
two
layers,
two
layers,
the
second
time
the
net
result
is
now
one
layer
on
renegotiation.
E
E
E
And
similarly,
on
the
offer
side
can
the
offer
remove
a
previously
negotiated
layer
and
would
that
violate
rfc
8853,
provided
then
that
result
was
the
same.
So
this
gets
a
bit
complicated,
but
I
guess
the
general
question
is:
what
modifications
should
we
allow
after
initial
negotiation?
How
rigid
are
we
and
it
seems
like
we
all
agree
that
as
provided
the
net
result
is
the
same?
E
E
E
A
No
because
that's
been
the
current
behavior
and
part
of
the
spec
for
a
while,
so
I
don't
think
we
should
reject
if
you
know
it
right
now,
we
have,
I
believe,
some
limitations
in
some
implementations.
Let's
say
that
you
cannot
have
too
many
summer
cast
layers,
so
they
are
trimmed
after
a
certain
point
and
that's
been
a
core
feature
for
a
while
we
relied
on.
So
if
we
don't
have
that,
it's
not
going
to
work.
E
A
But
using
author
would
make
sense
possibly,
but
I
don't
see
a
lot
of
scenarios
where
that
would
actually
succeed
if
the
client
rejected
it
once
it
will
probably
be
rejected
again
and
that's
fine,
because
it's
going
to
be
trimmed
by
the
client
again.
So
I
don't
see
the
problem
with
that
expanding
it
to
more
than
where
accepted,
probably
not
making
sense.
I
don't
see
the
problem
in
rejecting
it,
because
the
client
will
just
say
hey.
You
asked
for
10
layers,
but
I
can
only
do
three
anyway.
So
I'll
answer
free.
E
Okay,
I
think
that
sounds
good
and
I
apologize
for
using
the
word
reject
here,
because
it's
a
bit
ambiguous
what
I
mean
so
you're
talking
about
rejecting
as
in
reducing
layers
right,
yes
and
and
there's
also
a
question
of
whether
we
should
a
set
remote
description
should
fail,
which
is
another
form
of
rejection.
I
suppose
so
it
sounds
like
we
have
agreement
that
we
should
allow
reducing
number
of
layers,
but
not
increasing
number
of
layers.
A
E
E
E
B
A
E
D
B
E
E
B
B
E
E
D
E
B
E
E
B
E
B
C
B
E
So
I
don't
know
that
we
want
to
do
that,
but
it
also
seems
that
the
current
language
is
a
bit
too
strict
and
we
should
at
least
modify
it
so
that
existing
use
doesn't
violate
it,
at
least
for
sensible
use
and
determining
sensible
use
might
be
where
we're
hoping
for
implementers
to
provide
more
feedback.
What
about
what
sfvs
are
doing
today?
E
B
C
B
B
A
A
small
comment
before
24.:
if
we
allowed
to
renegotiate
the
reads,
that's
at
the
sdp
level
and
we
don't
have
any
apis
in
the
javascript
level
to
be
able
to
do
similar
things
right
now.
The
only
thing
that
would
match
would
be
set
parameters,
but
we
explicitly
say
that
it
should
not
trigger
a
renegotiation.
A
So
we
don't
underlow
changing
the
amount
of
summercast
layers
or
changing.
The
reads
is
that
something
we
want
in
the
future
to
be
able
to
have
something
that
says:
hey
in
the
next
renegotiation.
Please
have
those
layers
or
an
extra
parameter
and
set
parameters,
say
trigger
a
negotiation,
because
I'm
changing
the
layers,
that's
something
for
the
future
to
think
about.
Well,.
A
B
D
E
B
E
E
E
B
B
E
E
So
the
question
is:
is
that
what
the
language
was
intended
for
and
when
reading
these
two
together
means
this
only
removing
only
works
in
the
initial
offer
answer,
because
that
would
satisfy
both
criteria
or
it's
the
sentence
once
the
envelope
is
determined
layers
cannot
be
removed.
Is
that
wrong
because
it
seems
hard
to
refute
the
intent
on
the
first
sentence.
E
So
they're
definitely
seen
but
there's
some
flaws
here
already-
and
this
is
the
ad
transceiver
method
establishes
the
simulcast
envelope,
which
was
true
originally,
but
then
we
also
added
the
ability
for
the
remote
and
sfus
to
operate
to
receive
simulcast.
So
there's
actually
two
ways
to
establish
the
envelope.
Now,
at
least.
B
E
So
maybe
that
is
the
that
is
the
outer
envelope
which
is
described
as
a
maximum.
So
in
that
case
the
example
we've
been
using
for
the
offer
is
for
three
and
the
answers
for
two:
the
envelope
would
be
for
three
and
which
means
we
could
allow
we
couldn't.
We
could
enforce
three
as
a
limit
which
would
allow,
which
is
quite
flexible.
I
think
it
allows
an
answer
to
reject
sorry
to
reduce
the
number
of
layers
and
increase
the
number
layers
up
to
that
number.
Three
in
this
example.
E
B
We
may
be
over
alerting
the
term
simulcast
envelope
in
that
it
there
may
be
there's
multiple
things.
I
think
we
have
to
figure
out
here.
One
is
interactions
between
transceiver
and
set
parameters.
What
we
allow
and
don't
allow-
and
the
other
is
all
the
other
offer
answer-
interactions
that
you've
described
earlier
and
those
I
think
using
the
term
sonic
as
envelope
may
not
be
helpful,
because
it's
it's
confusing
very
confusing
the
way
it
is
right
now.
B
E
A
I
mean
changing
the
envelope
through
set
parameters
after
negotiation
is
definitely
not
something
we
want
to
be
able
to
do,
as
is
because
that
would
imply
a
renegotiation
later
on,
I
believe,
but
before
negotiation.
That
may
be
something
we
could
allow.
I
don't
have
a
lot
of
opinions
about
the
rest.
B
Yeah
I
mean
I
mean
one
question:
is
you
know
we
don't
necessarily
have
to
allow
stuff
if
there
isn't
a
use
case
for
it.
All
I'm
reacting
to
here
is
that
it
just
seems
really
unclear.
What's
allowed
and
what's
not
so
if
I
read
this,
I
wouldn't
have
any
idea,
and
it
we're
just
conflating
so
many
things
that
I
wouldn't
have
any
clue
as
to
what
should
be
allowed
or
what
to
expect
that's.
My
problem.
E
B
You
know
we
have.
We
have
a
bunch
of
you
have
a
bunch
of,
I
think
sonic's
envelope
is
the
right
word
to
use
in
the
issues
that
relate
to
what
the
offers
and
answers
can
do
relates
to
negotiation.
But
if
we're
trying
to
figure
out
what
how
the
in
potential
interactions
of
that
transceiver
and
set
parameters,
that
might
not
be
the
right
word.
B
B
And
I
I
think
the
term
samakasa
may
not
be
quite
right
for
that
and
then
there's
the
whole
question
of
what
of
the
other
set
of
things
you
raised
yanima,
which
was
you
know,
changing
things
and
answers,
and
all
you
know
reoffers
and
answers,
and
all
that
and
then
the
simulcast
envelope
term
may
be
the
correct
one
for
that,
even
though,
in
some
cases
that
isn't
even
clear
to
me,
because
it,
I
think
the
purpose.
The
overall
purpose
of
this
paragraph
was
to
try
to
tell
you
what
set
parameters.
B
E
So,
in
order
to
iterate,
maybe
we
can
iterate
on
this.
By
saying
I,
I
didn't
hear
any
objections
to
the
first
line,
whether
I
had
a
checkbox
on,
which
was
that
everyone
seemed
to
agree
that
if
you
got
the
same
offer
answer
exchange
again,
then
everything
that
should
succeed.
So
we
can
at
least
loosen
since
our
current
language
is
even
stricter
than
that.
We
can
at
least
clarify
that
piece.
Maybe
right
right.
B
B
D
B
A
E
B
E
B
I
think
is
this:
do
we
actually
even
need
this
issue
or
has
have
we
covered
pretty
much
everything
here
with
2724
and
2722?
I
think
we
know
that
samacast
encodings
can
be
removed
so
anyway.
I
think
this
is
an
issue
really
about
the
whole
text
of
summer
cast
envelope
and
the
fact
that
it's
very
confusing,
I
think
we
can
agree
to
that.
E
But
if
we
can
agree
with
the
behavior
we
want,
it
sounds
like
we
agreed
that
we
can
allow
renegotiations
only
if
they
produce
the
same
result,
which
is
right
right,
results.
A
lot
of
the
questions,
which
means
that
a
lot
of
the
anguish
language
about
removing
layers,
while
true
you
can
only
remove
layers,
if
you
did
it
the
first
time
in
order
to
produce
the
same
result.
So
the
net
result
should
be
that
javascript
has
a
consistent
when
it's
reading
get
parameters.
B
B
Well,
he's
not
a
bird,
but
I
actually
did
get
a
picture
of
him
where
he
was
moving
fast
enough
to
actually
blur
the
picture,
which
was
very
surprising,
but
in
this
particular
picture,
he's
just
walking
very,
very
slowly,
putting
one
foot
in
front
of
the
other
or
a
paw.
I
guess
in
front
of
the
other,
and
he
was
out
on
the
boardwalk
in
the
sun.