►
From YouTube: IETF110-RUM-20210310-1430
Description
RUM meeting session at IETF110
2021/03/10 1430
https://datatracker.ietf.org/meeting/110/proceedings/
C
A
A
B
B
A
B
B
A
A
B
D
B
E
Okay,
the
only
thing
that
I
just
wanted
to
ask
about
the
agenda.
I
believe
we
would
like
to
you
know
talk
about-
maybe
some
of
the
open
issues
that
we
had
talked
about
on
the
email
that
maybe
haven't
been
resolved
and
and
perhaps
bring
up
another
couple.
I
guess
your
agenda
is
allowing
for
that
right.
A
Correct
other
we,
I
have
a
number
of
items
that
I
think
have
not
been
resolved,
that
I'm
gonna
gonna
talk
about,
and
anyone
else
is,
though
there
will
be
time
at
the
end
for
bringing
up
other
issues.
So,
yes,
we
will
we're.
Definitely
thinking
we're
going
through
the
issues
that
are
raised
on
the
list
and
and
anything
else
people
want
to
talk
about
will
have
time
at
the
after
that
to
to
work
on
them
perfect.
Thank
you.
F
A
Yeah
yeah,
the
slides,
are
up
on
the
meeting
materials
page
but
I'll
get
to
them.
I'm
going
to
switch
as
soon
as
we
agree
that
that's
the
only
thing
we
have
to
do.
I
will
switch
slides
and
it
shows
you
the
issues
that
I've
I've
got,
but
the
slides
I'm
going
to
present
are
are
in
the
meeting
materials
section.
A
A
A
I
think
we
have
dealt
with
the
other
issues
that
have
been
raised
on
the
list,
but
I
may
have
missed
something
and
I'm
again
this
will
go
fairly
quickly,
and
so
I
think
we'll
have
lots
of
time
to
bring
up
other
issues
and-
and
so
I'm
I'm
anticipating
that
I've
probably
forgotten
something
or
not
realized.
Someone
doesn't
think
that
something
I
think
is
closed
or
settled
is,
is
settled
and
so
we'll
we'll
definitely
have
plenty
of
time.
After
this
to
talk
about
things
that
aren't
on
that
list,.
A
That
says,
devices
should
only
accept
incoming
calls
from
entities
they
they're
provisioned
with,
and
then
how
does
that
interact
with
outbound,
and
so
that
that
whole
issue
is
still
kind
of
running
around
the
the
direction
I
think
we're
going
is
what
paul
hinted
at,
which
was
outbound
proxies.
If
there
are
multiple
outbound
proxies,
inbounds
are
only
allowed
from
those,
and
any
of
them
can
be.
B
It
was
my
issue,
so
let
me
try
to
clarify
a
little
bit
sure
we
have
the
we
have,
the
configuration
of
quote:
outbound
proxies
yeah
specified.
We
also
have
listed
that
support
of
the
outbound
functionality.
I
forget
the
the
rfc
number
right
now,
but
yes
it
it's.
The
specific
functionality
is
optional
for
the
provider:
correct,
not
optional,
for
the
for
the
room.
B
A
B
B
B
A
B
A
A
A
B
A
A
If
you
specify
more
than
one
proxy
on
the
outbound
configuration-
and
you
know
it,
it
is
it's
more
common
to
have
only
one
right
that
that's
the
more
common
circumstance,
but
multiple
for
redundant
renunciate
purposes
and
other
purposes
is
often
helpful.
But
let's
just
say:
let's
just
ask
a
question:
if,
if
we
proposed
it
that
way,
if
we
said,
if
you
specify
more
than
one
proc
outbound
proxy
in
the
configuration
that
means
you
must
support
the
outbound
rfc
and
then
we
know
what
multiple
outbound
proxies
mean.
A
G
G
G
G
E
E
A
A
A
B
G
Yeah
so
you're
saying
that
the
outbound
the
configured
outbound
has
to
be
treated
as
any
other
cpri.
So
we
go
to
dns
resolution
first
and
unless
we
have
dns
resolution,
it's
a
host
name
and
then
you
have
a
single
outbound
server.
But
if
you
have
dns
you
you'll
get
the
benefits
of
failover
and
load
balancing.
B
G
Then
have
to
do
failover
between
those
different
reg
ids
for
the
same
contact
which
very
few
carriers
have,
and
we
have
never
been
able
to
test
that
cpit
that
it
works
properly.
The
only
practical
use
of
the
zip
up
on
our
crc
today
is
in
c
power
web
sockets
that
is
actually
used,
but
only
with
one
registration,
but
since
the
contact
is
useless,
the
reg
id
is
the
only
thing
we
have
to
be
able
to
call
back.
A
A
G
A
B
C
B
A
Well,
I
I
g
that
sounds
good.
I
I
my
my
own
experiences
in
weird
circumstances:
the
911
environment,
where
things
like
connection
redundancy
and
things
like
that-
are
much
more
important,
so
but
they're
unusual.
So
my
experience
is
probably
not
relevant
to
what
for
this
application,
but
it
the
connection,
reuse
and
fostering
good
tcp
connections
and
not
having
to
hack
around
with
nat
traversal,
and
you
know
that
all
that's
really
good
stuff,
and
if
we
can
keep
that,
I
I
think
that
would
be
worthwhile.
G
Then
we
can
copy
a
lot
of
the
text
from
the
rc
or
simple
web
sockets
which
implements
kind
of
that
part
of
outbound.
As
paul
mentioned
yeah,
I
usually
call
it
half
outbound,
because
it
doesn't
require
anything
special
in
the
proxy
just
finding
the
incoming
connection
and
use
that
route
bomb
seek
messages.
H
B
G
C
B
B
B
B
F
On
that
point,
that
that's
definitely
one
of
the
concerns
we
had
is
that
mobile
devices
they
all
they
all
require
some
type
of
push
notification
now
to
do
an
inbound
call,
and
we
don't
we
don't
have
anything
for
that.
So
I
don't
know
if
we
assume
we
want
inbound
calls
right
yeah.
I
would
expect
that
so
it's
hard
to
understand
how
this
would
even
be
usable
by
anybody
without
some
mechanism
for
mobile.
G
F
Yeah
well,
no,
but
if
you're
not
already,
if
you're
not
already
registered,
you
need
some,
you
need
some
kind
of
a
redirect
or
something
so
that
once
the
client
wakes
up
and
and
also
how
does
it
get
the
push
notification
in
the
first
place
right,
you
need.
You
need
something
like
a
device
token
to
identify
the
device.
H
F
F
A
A
G
So
it
does,
it
doesn't
conflict
with
that.
Another
problem
with
the
outbound
rc
that
we
need
to
mention
is
that
it
implements
a
pre-forking,
for
that
was
complicated
for
many
simple
implementations
that
you
have
a
fork
between
the
different
regis
for
the
same
contact,
and
then
you
handle
the
next
contact
in
parallel
or
in
syria.
C
B
B
G
G
But
we
implemented
in
many
places,
push
notifications
and
camilo.
What
we
best
basically
have
to
do
is
a
way
to
freeze
the
sip
transaction
while
the
push
is
taking
place
and
we're
waiting
for
an
incoming
registration
when
we
have
an
income
administration,
we're
forwarding
white
quickly
as
quick
as
possible.
A
F
B
F
Refresh-
and
this
is
all
fairly
recent
in
the
last
few
years-
I
mean
yes,
that's
right
apple
used
to
allow
you
to
run
the
app
in
the
background
and
stay
registered,
and
then
they
did.
They
allowed
the
voip
connection,
which
allowed
you
to
wake
the
up
gap
up
with
the
tcp
connection,
but
more
recently,
they've
completely
shut
that
down.
The
app
cannot
run
at
all
unless
it
gets
a
push.
G
A
A
A
All
right,
oauth
we've
had
this
has
been
discussed
several
times.
We
haven't
got
any
text,
we
need
to
decide
if
we're
supporting
oauth
and
if
so,
for
what
we
could
support
oauth
for
authentication
for
the
configuration
info.
We
could
support
oauth
for
authentication
for
sip
or
we
could
do
both
and
if
we
do
have
a
role
for
oauth
is
that,
instead
of
or
in
addition
to
username
password
for
any
of
those
possibilities.
A
F
F
A
A
It
would
be
an
alternative
to
having
configured
username
passwords
that
are
used
in
you
know,
directly
with
register
and
with
any
any
of
the
authentication
mechanisms
that
you
use
with
with
with
sip
or
with
the
configuration
service
yeah
the
the
username
password
is
there.
I
do
remind
you
that
oauth
ultimately
uses
a
username
password.
It's
just
that.
There's
been
tokens
and
tokens.
Can
that
be
shared
and
used
and
can
be
minted
and
then
used
subsequently,
and
things
like
that.
So.
G
F
A
G
G
Is
sip
has
been
around
for
a
very
long
time
when
zip
was
created,
the
best
authentication
we
had
was
http
basic
digest,
auth
with
md5
hash
method,
we're
now
in
2021
and
we're
setting
new
standards.
Md5
is
considered
broken
since
a
long
time
in
the
sip
standards.
We
have
two
different
options.
At
least
we
have
one
rc
that
have
replaced
md5
with
stronger
hash
algorithms
right
that
will
possibly
die
in
ten
years
or
five
years
or
whatever,
depending
on
cpu
and
other
things.
G
G
But
it
it
gives
us
a
lot
more
possibilities,
so
you
authenticate
somewhere
else
in
a
ui.
There
are
ways
to
do
that
this,
without
uis
with
your
tokens
of
some
kind
or
other
things.
But
the
result
is
we
get
tokens
that
the
sip
server
verifies
with
an
identity,
server
that
they're
valid
and
if
we
have
trust
between
the
auth
idp
and
the
sip
server,
we're
all
ready
to
go.
F
G
F
G
F
All
right,
that's
how
it
works.
I
trust,
google.
I
trust
that
google
is
not
going
to
compromise
my
password,
so
I
that
I
mean
that's
kind
of
big
the
whole
basis
right.
I
know
I'm
talking
to
google.
I
trust,
google.
I
give
them
my
password
all
right
so
so
I
trust
I
trust
sorensen
as
a
brs
provider.
I
can
see
and
verify
that
I'm
really
talking
to
their
server,
so
we
can
go
on
this
forever,
but
I
think
so.
B
F
A
F
G
A
A
What,
in
addition
to
is
that?
Well
let
me
let
me
ask
this
you've
been
very
vocal
that
you
think
it's
the
right
thing
to
do
is
there's
someone
else
on
the
call,
and
I
will
we
will
bring
this
to
the
list.
So
this
is
not
the
definitive
word,
but
if
there's
someone
else
in
the
meeting
who
believes
that
it
is
appropriate
to
require
every
implementation
of
the
rue
device
to
support
oauth
as
an
alternative
authentication
mechanism
instead
of
the
existing
sip
mechanisms
and
presumably
for
the
config
info,
the
http
mechanisms
is
that
is
there?
A
A
Well,
so
I'm
now
looking
is
there
someone
else
who
thinks
that
that's
a
reasonable
that
that's
what
they
want
to
do?
They
want
to
have
oauth
implemented
on
all
devices
and
optional
at
the
provider
to
use
with
the
existing
sip
and
http
mechanisms
mandatory.
You
know
basically,
both
ways
right.
You
know
you
can
you
can
choose
to
use,
only
oauth
you
can
choose
to
use
only
username
password
is.
H
G
A
So
it
just
seems
to
me
that
there's
no
one
else
on
the
call
and
again
we
will
bring
this
to
the
list
that
supports
it,
and,
although
I
I
like
it,
I
think
it's
a
great
idea.
I
don't
see
anyone
saying
they
want
to.
You
know
they
want
to
be
forced
to
implement
it
on
the
ruse
side
and
unless
there's
more
than
you
who
wants
it,
you
know,
I
think,
we're
in
the
rough
consensus
saying
we
don't.
G
A
I
want
to
again
I'm
going
to
go
to
the
list
on
this,
but
the
other
issue
you
raised
is
an
important
one
and-
and
I
I
hope
that
the
folks
on
the
call
will
will
speak
up
but
as
if
you
know
anything
about
crypto
md5
is
the
is
an
algorithm
that
has
been
broken.
It's
it's
just
too
easy
to
crack
and
up
to,
I
can't
remember
the
number
but
there's
a
relatively
recent
rc
that
substitutes
sha
256
for
md5
in
basic
in
in
in
authentication.
B
A
B
A
H
F
F
A
G
Get
a
is
that
it
also
implements
a
negotiation
method
that
can
lead
to
interesting
downgrading
attacks.
It
opens
up
not
for
a
single
hash
algorithm,
but
for
multiple
and
a
negotiation
that
is
rather
complex.
We've
been
testing
this
something
called
opencipit
last
year
and
we're
gonna
continue
testing
it
to
get
implementation
experience.
G
F
A
Well,
there's
there's
a
you
need
a
transition
issue
path.
So
so
I
I
think
that
that's
probably
right,
but
you
want
to
drop
dead
date.
You
want
to
you
you
and
I
I
don't
think
that
we
could
put
a
date
in
the
rc.
So
I'm
not
talking
about
that,
but
you
want
to.
Yes,
you
need
transition,
because
you
can't
you,
you
can't
upgrade
everything
instantly,
but
you
really
do
want
to
get
rid
of
md5.
It's
really
insecure
at
this
point
really
seriously.
A
E
G
H
B
Got
it
got
a
shitload
of
devices
out
in
the
field?
You
know
they
aren't
root
compatible,
but
but
you
know
that
yeah
when
they
start
supporting
the
roof,
they're
still
going
to
have
to
support
their
old
devices
for
some
period
of
time,
and
if
those
devices
you
know
authenticate
using
md5,
their
accounts
at
least
have
to
support
that.
You
know.
A
A
G
G
G
A
F
A
Okay,
let's
again
I'll
take
a
crack
at
some
words
and
we'll
and
we'll
raise
it
on
the
list
and
see
where
we
are,
but
I
think
that's
the
way
we're
heading
is
support.
256
must
support
256
on
the
root
device,
with
the
with
a
transition
mechanism
for
providers
to
ease
over
all
right.
Now.
What
have
I
forgotten?
What
have
we
not
talked
about
that
people
believe
are
still
open
items.
F
Hey
this
is
isaac,
so
a
big
one
is
a
big
one.
In
my
mind
is
ipv6.
It
seemed
that
just
got
added
fairly
in
the
one
of
the
most
recent
updates,
but
then
there
was
a
comment.
That
was
something
to
the
extent
of
well.
It's
no
big
deal.
You
just
put
the
client
behind
the
gateway,
so
we
don't.
You
know
it's
no
big
deal.
F
A
I
mean
at
least
the
way
I
know
people
do.
This
is
the
spc.
Does
it
because
it's
a
b2b
ua
and
it
doesn't
really
matter
what
happens
on
the
inside
of
the
network
and
it
only
matters
what
happens
on
the
outside
of
the
network
and
as
long
as
the
sbc
can
be
to
be
ua
on
an
ipv6
address
with
media
you're.
Sad.
G
F
G
F
A
F
So
they
they
provide
the
nas
64
gateway,
it's
not
the
provider,
that's
doing
that,
64
gateway,
they
do
it,
but
there
are.
There
are
some
things
that
we
had
to
solve.
Like
you
know,
for
example,
in
the
stp,
you
use
ip
literals
right,
but
you
can't
really
start
shoving.
Ipv6
addresses
in
your
sdp
without
well,
you
can
you
can,
but
if
the
other
providers
aren't
doing
it,
then
your
sdp
doesn't
work
right.
Well,
let's
say
you're
doing,
let's
say
you're
doing
a
call
with
an
ipv4
client
on
desktop.
F
A
F
B
F
Like
there's
a
whole
bunch
of
things
we
got
to
solve,
if
or
at
the
very
least
we
say,
look
the
the
providers
are
still
ipv4
and
you
know
you're
going
to
have
this
gateway.
But
there's
you
know
a
big
one
is
like
the
public
ip
address.
We
need
a
public
ip
address
for
the
for
our
cdrs
for
the
fcc
billing,
and
so
we
can't
I
don't.
I
don't
know
that
we
can
submit
an
ipv6
address.
F
They
aren't
using
the
well-known
prefix
so
t-mobile,
I
think,
uses
a
prefix
with
like
2600
and
every
every
once
in
a
while
they'll
start
using
a
new
one
and
then
we're
like.
Oh
crap,
we
got
a
brush,
have
it
fixed,
so
it
would
be
great.
Somebody
could
solve
that
for
us
right,
but
we've
had
to
we've
had
to
kind
of
jump
through
some
hoops
and
and
do
some
things
that
aren't
in
an
rfc
or
a
standard
anywhere.
F
C
B
A
B
A
A
We
are
out
of
time.
I
I
just
wanna.
If
I
can
indulge
you
a
little
bit,
has
anyone
else
got
an
issue
that
has
not
if,
if
anyone
else
has
an
issue
that
has
not
been
discussed,
put
it
on
the
list,
please,
so
that
we
know
that
people
still
still
think.
There's
things
to
do
it
it.
It's
real
important
that
we
understand
what
we
need
to
do,
because
we
really
are
trying
to
finish.
We
clearly.