►
From YouTube: IETF106-RUM-20191121-1000
Description
RUM meeting session at IETF106
2019/11/21 1000
https://datatracker.ietf.org/meeting/106/proceedings/
A
A
A
A
So
this
is
the
rum
meeting
note
well.
E
A
All
right,
so
this
is
rum.
Well,
there's
the
agenda
really
just
talking
about
the
one
draft
and
where
we
are
in
the
open
issues.
Does
anyone
want
to
bash
the
agenda?
Anything
you
want
to
change
if
you're
participating
remotely
by
all
means
ask
to
speak
and
we'll
recognize
you
on,
including
bashing
the
agenda.
You're
certainly
welcome
to
do
that.
If
you
have
any
suggestions.
A
A
E
A
The
current
state
of
the
document
is
that
g.711
and
opus
are
mandatory
to
implement.
There
has
been
the
discussion
of
what.
What
does
it
mean
if
your
gate
wing
from
the
PSTN
and
I
think
that
we're
we've
agreed
that
that's
you
don't
have
to
offer
opus
if
your
gate
wing
from
the
PSTN
that's
the
silly
thing
to
do,
there's
no
requirement
to
be
silly
and
we
can
I.
A
Don't
we'll
make
sure
that
the
text
is
clear
on
that
subject,
I
did
try
to
do
that
on
the
current
version
is:
is
there
anything
that
people
think
that
they
want
to
see
in
the
audio
section?
That
is
not
there
or
if
we
solve
this
one
issue
having
to
do
with?
Yes,
you
have
to
implement
it,
but
you
don't
have
to
use
it
in
every
call.
F
Okay,
can
you
hear
me?
Okay,
yeah,
it's
not
terrific,
but
it's
it's!
It's
understandable!
Go
ahead!
Okay!
Oh!
So
what
I
did
post
something
on
the
email
list
about
supporting
devices
that
are
older
than
then
maybe
opus
would
be
able
to
run
on,
given
that
we're
already
pushing
the
limits
on
some
of
these
devices?
I,
don't
remember
who
some
Oh,
someone
posted
back,
saying
that
that
we
don't
plant
them
I,
guess
using
these
ancient
devices?
Here's
here's
my
concern.
F
My
concern
is
as
a
VRS
provider,
the
FCC
will
give
us
direction
based
on
you
know,
input
from
RFC's
and
so
forth.
If,
if
they
simply
say,
we
must
comply
with
this
RFC
without
any
caveats
about
our
older
devices
that
we
do
not
support
anymore
I
mean
we
don't
push
new
firmware
to
them.
That
best
concern
so
I,
I,
I
think
from
our
providers
perspective.
A
G
A
C
Yeah
yeah,
so
just
from
my
own,
you
know
following
the
list
I
think
generally
I
can
arm
m3,
which
is
sort
of
the
very
like
embedded.
Arm
chips
are
able
to
run
opus
with
only
a
little
bit
of
tuning
because
I
understand
it
so
yeah
they
running
video
as
well,
if
you're
running
video.
So
if
you
have
to
run
video.
H
A
Yeah
I
mean
making
we're
this
is
Brian
and
I.
I
I
do
think
that
we're
in
we're
the
the
load
that
opus
places
on
a
cpu
is
very
small
compared
to
what
video
does
and
unless
you're
running
at
99%,
CPU,
utilization
and
1%
will
take
you
over
and
I.
Can
imagine
that
you
could
be
in
a
circumstance
like
that,
but
it's
you
know
I
hope
you
aren't,
but
but
I
think
the
the
real
problem
is
that
getting
a
document
through
the
ITF
requires
that
we
do.
You
know,
put
our
best.
A
Current
practice
in
an
opus
is
clearly
our
best
current
practice,
and
you
know
we
can
make
accommodations
for
backwards
compatibility.
That's
always
a
possible
thing
to
do,
but
in
terms
of
meeting
the
requirement,
so
the
device
meeting
the
requirements
of
us
of
a
new
specification
that
it
would
be
very
hard
to
get
it
through
the
a
document
through
without
without
requiring
what
we
think
is
best
current
practice
all
right.
Thank
you.
Thank
you
appreciate
it.
A
A
I
A
D
J
A
J
Just
to
come
back
to
Richard
was
saying
I
think
our
problem
is
that
the
there
are
two
sides
to
the
rum
interface
there's
the
iue
itself
and
this
the
provider
side
and
the
way
the
documents
phrased.
I
think
the
provider
side
represents
essentially
the
interface
to
the
PSTN
and
a
whole
load
of
legacy.
J
A
A
Certainly
if,
if,
if
I'm
interpreting
it
correctly,
I
agree
with
you
you're
saying
that
that,
in
addition
to
gate
weighing
a
call
from
the
PSTN,
you
may
be
connecting
to
a
device
which
is
not
route
compliant,
and
you
want
to
be
able
to
establish
a
a
a
communication
with
room
on
audio
path
and
the
only
thing
offered
by
that
legacy
device
is
g.711,
and
you
want
to
make
sure
that
that
the
ROO
spec
clearly
allows
talking
to
a
device
that
doesn't
support
rum.
It
doesn't
support
opus
and
and
I.
A
Think
everybody
agrees
with
you
that
that,
if
you're
calling
a
device
which
is
not
Roo
compatible
but
is
otherwise
able
to
create
a
video
session
and
an
audio
session
using
g.711
that
that
that
that
should
be
fully
supported
by
a
device
conforming
to
the
document.
And
if
again,
if
the
wording
is
not
clear
on
that
point,
I'm
very
happy
to
work
with
you
to
make
sure
that
it
is
very
clear
on
that
point.
All.
C
A
A
All
right,
if
there's
nothing
else,
on
audio
I'm
gonna,
go
to
video
and
a
reminder
that
we
did
agree.
That
h.264
is
the
only
mandatory
to
implement
codec
and
the
question
I
have
for
the
room
is:
is
there
anything
other
than
what
WebRTC
says
about
h.264
that
we
need
in
the
document
it?
If
you
go
read
the
specs.
There
are
a
number
of
things
that
it
says
that
you
have
to
implement
in
order
to
maintain
streams,
and
you
know
restarts
and
all
that
frame
framing
all
that
kind
of
stuff.
A
B
Hi,
can
you
hear
me?
Okay,
yes,
you're,
fine,
awesome,
great!
Thank
you
one
issue.
We
do
have
with
providers
and
I'm,
not
sure
what
WebRTC
says
about
this,
but
we
need.
We
do
require
mode
one,
because
there
are
a
lot
of.
There
are
a
lot
of
devices.
They
can't
encode
our.
There
are
some
older
devices
and
codecs
that
weren't
able
to
do
mode
one,
and
so
they
would
end
up
sending
really
large
packets
that
ended
up
getting
fragmented.
B
A
A
I
certainly
would
encourage
anybody
to
who's
listening
or
you
know,
and
any
of
the
providers
or
anybody
else
interested
to
to
go
back
and
look
to
see
what's
in
the
WebRTC
spec
and
think
about
what
you
think
you
need
to
have
I'm
not
opposed
to
adding
some
more
requirements
if
that'll
get
us
more
backwards,
compatibility.
A
A
A
This
makes
it
compatible
with
any
other
device
that
does
real-time
text
with
sip
and
I.
Don't
think
there
is
anything
that
needs
to
be
done
there,
but
if
there
is
anything
that
people
want
to
bring
out
happy
to
talk
about
that
now,
but
I
think
we're
okay,
that
in
the
in
the
text
side,
any
any
comments
on
text.
A
This
providers
may
do
that,
etc,
and
I'd
like
to
propose
that
as
an
IT
after
app
that
that
really
doesn't
have
a
lot
of
relevance
to
the
kind
of
documents
that
we
typically
create,
we're
defining
a
protocol
or
really
were
profiling,
an
interface
and
I'd
like
to
see
if
their
support
for
getting
rid
of
that
wording
and
just
talk
about
the
interface
as
as,
what's
required
across
the
interface
and
and
that
that
you
know
speaking
to
our
VRS
provider,
u.s.
VRS
provider.
A
A
J
An
observation
and
I
guess
a
question:
surely
this
kind
of
situation
must
come
up
quite
a
bit,
for
example
in
pure
client-server
interfaces,
where
there's
definitely
one
side
which
is
different
from
the
other
and
I
think.
For
the
reasons
we've
said,
though,
there
is
a
difference
between
the
two
sides
in
this
interface,
in
the
sense
that
we're
standardizing
it
a
new
interface
to
what
is
a
range
of
systems,
some
of
which
contain
legacy
elements.
So
there
is
an
inherent
asymmetry
and
what
we're
trying
to
do.
A
You
you
most
certainly
have
two
sides
of
an
interface,
and
you
know
you
might
have
clients
and
servers,
and
the
server's
may
have
different
requirements.
The
clients
that
that
that's,
certainly
not
all
that
unusual,
but
usually
what
you
say
is
that
that
it
mean
but
but
we
don't
have
a
circumstance
like
that
here,
we're
really
talking
about
a
device
interfacing
towards
a
service.
It's
the
service.
A
You
know
the
what
in
the
the
PSTN,
we
call
the
Uni
interface
right,
it's
the
user
to
network
interface
and
what
happens
in
the
network
or
what
happens
to
some
other
device.
That's
connected
to
the
network,
or
anything
like
that
is,
is
outside
of
the
range
of
the
specification.
The
specification
only
talks
about
what
does
it
look
like
on
the
wire
between
the
end
device
and
the
the
the
network,
in
this
case
the
providers
network,
but
but
it,
but
that's
what
it
looks
like
it's
only
there
and.
A
That
that
means
that
you
don't
have
to
well
that
we're
not
saying
what
happens
inside
the
provider
network,
we're
only
saying
what
happens
on
the
connection
between
the
user
device
and
the
network.
Does
that
make
sense
to
you
and
is
that
helpful
in
in
in
in
in
getting
work
where
I'm
proposing
you
go.
J
J
A
H
In
in
in
the
VRS
provider,
specs
I
mean
we
have
a
more
complex
architecture.
Yeah
I
mean
it's
not
just
devices
talking
to
similar
devices
or
something
like
that.
You
know
we
have
roles
for
these
things.
So
you
know
the
provider
has
a
rural
separate.
You
know
and
the
point-to-point
call
between
two
crews,
you
know,
is
topologically
different
and
so
I
I
think
that's
the
perspective
from
which
you
know
there's
a
symmetry
in
you
know,
and
so,
if
you
just
make
a
point-to-point
call,
then
it's
really
ruined.
H
There's
it's
all
fine,
but
if
the
roux
is
calling
and
it
ends
up
at
a
provider
it
may
be
talking
to
it.
You
know
an
IVR
kind
of
device
for
a
while
and
maybe
talking
to
a
to
a
conference
or
the
conference's
in
the
interpreter-
and
you
know
it's
technically
Elise
says
things
currently
stand.
There
is
no
requirement
that
the
devices
that
interpreters
that
work
on
the
arrests
use
meet
the
ruse
back
yeah
and
maybe
maybe
that'll
change
too,
but
so
to
me.
H
H
The
situation
is
different
if,
if
the
FCC
is
going
to
issue
a
regulation
that
refer,
you
know
that
for
which
the
respect
is
one
part
and
there's
you
know
like
other
parts
for
backward
compatibility
or
something
like
that.
Then
it
is.
If
the
expectation
is
that
the
FCC
is
just
gonna
say
you
know,
everybody's
got
to
support
this,
and
it's
not
clear
to
me
how
we
sort
that
out,
but
I
think
it
would.
It
would
help
the
providers
if
they
knew
what
was
going
to
happen.
C
J
F
So
back
kinda,
what
James
is
saying
about
the
the
must
for
ruined
me
for
providers?
For
one
thing,
of
course,
let's
go
through
the
document
with
an
eye
with
that
in
mind
and
understand,
trying
to
see
how
that
was
well
play
out.
F
I
I
did
briefly
just
run
through
the
document
looking
for
muss
and
May,
and
one
one
jumped
out
at
me
and
I'm
wondering
how
oh
you
would
deal
with
this
with
your
your
your
current
approach
and
it's
it's
a
paragraph
in
section
five,
it's
in
addition,
the
room
must
and
providers
may
conform
to
an
ELISA
series
series
of
RCS
like,
for
example,
one
of
them
is
ice
and
as
far
as
I
know,
I
think
Sorenson
is
the
only
provider
that
uses
ice
today.
So
how
would
you
go
about
rewriting
that?
A
A
But
that's
the
way
ice
is
built
anyways,
so
I
I,
think
you're,
probably
okay,
but
I.
Think.
But
you
know,
I
think
your
your
your
intuition
of
look
well,
let's
go
look
at
the
cases
where
they're
asymmetric
and
decide
whether
there's
a
problem
is
probably
the
right
one
and
when
we'll
do
that
and
I
found
another
one
which
is
in
5-3
and
it
so
it
that
one
is
Roo
must
and
providers
should
support
info
requests.
A
Well,
you
know
again
the
same
thing
across
the
interface
you
should
allow
the
info
request
and
and
whether
it
comes
up
that
is
whether
it's
ever
sent
is
is
is
is
an
issue,
but
if
you
get
it,
you
should
handle
it
and
I
I.
Think
that
that's
that
that's
where
the
that's
more
of
a
the
example
that
I
had
where
I
don't
think
that
we
should
have
an
asymmetry
in
the
sense
of
across
the
interface.
An
info
should
be
supported.
F
C
A
When
we
started
the
work
and
I
brought
in
the
original
draft,
which
was
based
on
work,
that
mitre
had
done
on
that
the
FCC's
behest,
there
were
a
couple
of
things
that
were
flagged
as
maybe
they
would
survive
in
the
ITF
draftin.
Maybe
they
wouldn't
and
I'd
like
to
start
the
discussion
of
what
survives
and
what
doesn't
the
two
things
that
I
know
about
that
are
worth
talking
about?
Are
the
provisioning
mechanism
and
the
contacts
mechanisms
provisioning?
A
Currently
in
the
draft,
there
is
a
provisioning
mechanism
which
works
by
discovering
and
downloading
a
JSON
object
that
provisions
the
device
there's
a
known
issue
with
that
having
to
do
with
usernames
and
passwords,
which
we
would
have
to
come
up
with
an
alternative
for
the
the
question
I
have
for
the
room
and
the
people
on
the
call
is
our
is
this:
do
we
want
to
keep
it?
I
personally
would
like
to
keep
it
think.
A
A
There
was
discussions
of
using
other
mechanisms
that
the
ITF
is
defined,
but
I
think
this
is
probably
what
people
would
first
see
so
other
than
how
we
handle
user
name
and
password.
Are
we
keeping
it?
Is
it
alright
to
keep
it
or?
Or
is
it
something
that
we
we're?
You
think
we'll
have
enough
trouble
coming
to
agreement
on
I'd
like
to
leave
it.
So
this
is.
We
discussed
whether
this
happens.
I'm
asking
the
question
now.
I
personally
would
like
to
keep
it
as
it
is
pretty
much
fixing
the
username
and
password.
A
A
A
A
Section
9,
provisioning
and
provider
selection,
and
if
you
go
through
that
you'll
see,
there
are
really
two
one
for
the
provider
selection
and
the
other
for
the
provisioning
piece.
There
are
two
JSON
objects
defined
that
provide
all
of
the
data
for
choosing
among
multiple
providers
and
provisioning
for
a
given
provider
that,
but
that's
the
part
I'm
talking
about
section
9.
B
A
B
A
A
B
To
understand
who,
where
that's
coming
from
so
you're
thinking
that
could
just
be
something
that's
part
of
the
rule
and
if
it
needs
the
URL
needs
to
get
added,
there
would
need
to
be
a
new
version
of
it.
That
would
have
that
in
it.
Like
it
say,
for
example,
a
new
provider
comes
online
or
a
writer
goes
offline.
How
does
that
get
handled?
And
then
the
other
kind
of
follow-up
question
to
that
is
I'm,
not
even
sure
how
that
works.
B
A
A
The
way
it's
currently
described,
it's
not
clear
and
I
and
then
I
think
that's
a
fault
of
the
document
and
we'll
have
to
fix
it
whether
whether
a
device
is
allowed
to
are
required
to
support
more
than
one
registration
at
a
given
time,
but
ignoring
that
little
detail
where
it
doesn't
say
the
the
the
way
it's
described.
You
have
entirely
separate
accounts
with
entirely
separate
telephone
numbers.
A
A
Problem
and
and
and
please
send
I
I
agree.
We
want
to
clarify
that
part.
So
if
you
wouldn't
you
know,
if
you
wouldn't
mind,
reading
it
and
strengths
them,
some
text
suggestions,
I'd,
appreciate
it,
but
I'll
take
a
look
at
it
and
try
and
prove
it,
because
I
I
agree
that
it's
not
very
clear,
just
sort
of
launches
into
the
mechanism.
Without
a
discussion
of
how
it's
supposed
to
be
used.
H
H
H
But
in
addition
it
would
have
you
know,
a
mechanism
to
to
do
what's
called
one
stage
dialer
round,
which
would
you
know,
allow
you
to
just
click,
a
button
to
say
which
provider
you
wanted
to
place
a
particular
call
through
when
you're
Flint
placing
outgoing
calls
and
then
then
your
call
would
be
outbound,
which
I
think
would
address
part
of
what
was
previously
being
asked
about.
Yeah.
A
A
H
The
other
thing,
I
think,
is:
if
we're,
if
we're
trying
to
have
this
deal
with
hearing
users
that
that
have
video
support,
then
I
think
there
would.
There
would
have
to
be
a
mechanism
for
them
to
get
their
get
their
route
like
device
configured
so
II
either.
The
existing
providers
would
somehow
have
to
be
able
to
support
hearing
users
with
with
with
with
route
of
Isis,
which
is
it
currently
within
their
mandate,
or
else
there
would
have
to
be
some
other
pseudo
pseudo
provider
that
provided
that
service,
like
what
mitre
sort
of
does.
H
But
I
think
you
know
between
those
things.
I,
you
cover
all
the
possibilities,
but
like
I
say,
the
original
imagined
mechanism
was
that
when
you
turned
on
a
brand
new
route
or
something
like
that
it
would,
it
would
know
where
to
go
to
fit
to
fetch
this
list
of
providers
and
then
it
would
bill
such
that
and
then
basically
provide
you
some
sort
of
configuration
mechanism
that
picks
what
people
want
the
one
you
want
and
then
it
would
go
through
the
the
provisioning
mechanism
with
that
one
mm-hmm
and
then
and
then
you'd
be
set.
H
B
I
just
wanted
to
clarify
that
it
has
nothing
to
do
with
a
hearing
user
using
video
or
a
roué
client,
or
anything
like
that.
It's
just
when
a
hearing
person
places
a
call
to
a
deaf
number
that
that
call
gets
routed
to
the
provider
that
owns
that
number
yeah,
there's
no
way
I,
just
don't
see
a
reasonable
way
that
you
would
have
a
hearing
call
going
to
one
provider
and
then
somehow
routed
to
another
provider.
B
So
this
idea
of
one
stage
dial
around
where
the
user
just
picks,
which
provider
they
want
to
use
there
might
be
some
ways
to
make
that
work
for
an
outbound
call,
but
it
just
it's
not
bi-directional
and
doesn't
really
seem
feasible,
given
that
so
I
just
wanted
to
add
that
clarification
for
Paul.
Thank
you,
yeah.
A
I
agree
with
you
Isaac
your
your
that's.
What
I
think
all
right
I,
what
I'm
hearing
is
leave
it
as
it
is,
but
make
the
text
clearer
about
how
this
mechanism
is
supposed
to
work
which
I
will
do
I
will
do,
and
if
anybody
has
to
text
suggestions,
send
them
to
the
lists
and
I'll
try
and
incorporate
them
in
the
next
version.
A
A
Okay,
then,
the
next
one
is
contacts.
So
the
current
document
has
two
mechanisms
for
context:
there's
an
upload
and
download
of
a
file
of
J
cards
and
then
there's
real-time
sink
using
CalDAV,
not
called
F
I
wrote
the
wrong
thing:
carddav.
Sorry,
that's
carddav
not
called
AB.
It's
not
calendars,
its
context
and
I.
B
Isaac
yeah
I
just
want
to
mention
that
you
know
really
the
issue
with
carddav
is
that
it's
fairly
limited
and
compared
to
what
you
know
some
of
the
things
we
do
with
our
current
contacts,
especially
for
deaf
users,
where
we
implement
things
like
visual
caller
ID,
whether
that's
color
or
patterns
there
are
just.
There
are
a
lot
of
things.
We
do
sherry
and
sharing
contacts
across
users
and
groups.
I
mean
the
card
card.
Dab
is
just
pretty
limited
in
comparison
like
it
might
might
be.
B
You
said:
well,
you
just
want
this
to
describe
the
interface,
but
if
it
says
the
interface
is
carddav
and
then
later
the
FCC
comes
along
and
says:
well
providers
must
be
compliant
with
the
Rome
profile
or
whatever
it's
called
now.
Then
it
effectively
becomes
a
must
and
requires
us
to
do
something.
That's
just
not
a
good
doesn't
provide
a
good
user
experience.
B
B
A
A
But
even
then
the
mechanism
allows
you
to
do
that.
It's
just
what
the?
How
does
the
server
we
know?
What
cards?
Does
the
server
send
you
and
and
as
you
say,
that
the
J
card
format,
as
with
the
X
card
format,
as
with
the
original
vCard
format,
is
extensible.
So
adding
extensions
for
things
like
a
visual
representation
of
the
user
in
some
way
is
is
certainly
straightforward
and.
A
And
yeah
I
mean
you
know
the
counter-argument
for
for
for
saying.
Well,
you
know
providers
do
that
all
is.
Do
some
providers
do
some
things.
You
know
it's
it's
yes,
but
that
makes
a
device
proprietary
unless
it's
using
some
kind
of
stand
that
multiple
multiple
ends
can
can
implement.
I
Paul
is
waiting
in
queue.
H
H
I'm
not
clear
I'm
how
you're
imagining
that
working
with
the
Roose
Beck?
Would
it
mean
that
would
it
fit
within
the
functionality
of
the
ruler
would
would
the
thing
that's
a
rule
also
have
to
have
extra
functionality
in
order
to
interface
with
your
contact
list,
especially
since
you
know
you
don't
have
a
call
when
you're
trying
to
use
the
contact
list
to
establish
a
call
and.
A
Way
it
works
now,
as
you
and
implied
the
the
whole
contact
list
is
is,
is
is
internal
to
the
provider
and
so
the
way,
the
way
you
move
contacts
from
one
provider
to
another.
Is
you
request
your
old
provider
to
send
you
a
file
of
your
contacts,
and
then
you
send
that
file
to
your
new
provider
and
he
uploads
it
into
his
service.
So
the
the
what
the
ROO
spec
makes
that
a
little
bit
better
right
it
just
it
says
that
you
do
they
upload
and
download
with
the
ROO.
H
I
I
agree
with
what
you
said
pretty
much,
but
I
think
there's
to
me:
there's
a
little
unclarity
still
whether
we're
really
talking
about
the
contact
list
or
if
we're
talking
about
you
know
as
a
as
a
as
a
piece
of
data
or
or
if
we're
talking
about.
You
know
that
contact
list
feature
that
the
end
user
uses
to
search
his
contacts
and
pick
somebody
and
use
one
of
them
to
make
a
call
and.
H
It
makes
a
difference
because
I
think
implicit
in
this,
although
it
doesn't
say
it
anywhere,
because
we
don't
talk
about
the
user
interface.
Is
that
with
the
respect?
Is
that
this
past?
This
contact
list
mechanism
is
just
a
way
to
get
the
list
of
contacts
into
the
root,
with
the
expectation
that
the
ROO,
somehow
or
other
you
know,
provides
its
own
user
interface
to
that
contact
list
for
the
user
to
use
for
making
calls
and
that
that
mechanism
then
mean
the
boundary
between
the
proprietary
part
and
the
non
proprietary
part.
H
Is
this
transfer
mechanism,
whether
it's,
whether
it's
you
know
carddav
or
whether
it's
you
know
upload/download
of
the
list
of
contacts
you
know?
And
but
that's
that's
different
from
a
from
a
mechanism
that
assumes
that
there's,
like
maybe
a
contact
list,
application
on
the
device
that
talks
to
some
server
mechanism
on
the
provider
that
that
provides.
You
know
like
a
web
interface
or
something
to
to
the
provider.
She.
You
know
that
that
offers
the
the
contact
list
mechanism
to
the
user.
H
H
Here
I
mean
I,
think
normally
an
end
user
nowadays,
I
mean,
of
course
the
you
know.
They
only
transfer
a
contact
list
if
they
decide
to
use
a
different
provider.
You
know
so
it's
something
you
do.
You
know
like
once
a
year
or
something
yeah
and
and
so
I
think
at
least
what
we
discussed
it
before.
The
mechanism
that
you
used
to
you
know
to
transfer
you.
Yes,
you
could
requested.
You
know
a
you
know
a
transfer
of
the
list,
but
it
wasn't
real
time.
H
It
might
take
weeks
to
go
or
you
know,
hours
or
something
to
get
it,
and
it
was
kind
of
like
a
manual
process
at
the
provider
and
or
at
least
maybe
not
up
a
little
bit
the
you
know
the
download
each
other
ways
which
here
I
mean.
It
certainly
is
imagine
this
is
a
real
time
function
and
that
you
know
in
principle
it's
just
an
optimization.
H
G
G
So
I
think
Paul
actually
has
a
good
point,
but
I
believe
we
can
get
away.
Sorry,
Adam,
Roach
speaking
as
an
individual
I
think
we
can
probably
get
away
with
just
defining
the
interface
here
without
having
to
get
into
how
the
device
uses
I.
Think,
like
all
the
modes
of
operation,
Paul
mentioned,
would
be
perfectly
valid.
G
But
what
I
got
up
here
was
actually
I
wanted
to
probe
a
little
bit
at
what
Isaac
was
saying
around
the
capabilities
of
B
card
and
J
card,
given
their
extensible
formats
and
the
two
examples
that
he
that
I
heard
him
give
all
this
at
least
were
visual
caller
ID,
which
I
presume
is
a
picture
based
approach.
We
like
have
contact
pictures
and
then
colors,
which
I
presume
is
categories
and
both
of
those
are
actually
supported
by
the
current
vCard
format.
G
But
I
I
would
be
really
surprised
to
the
capabilities,
given
that
it's
extensible
and
I'm,
looking
at
the
innn
and
registry
right
now,
and
it's
like
more
than
a
full
page
on
my
browser
of
fields
and
it
and
put
in
these
things.
I
would
be
really
surprised
if
they
weren't
covered
in
some
way
or
another
yeah.
B
B
Yeah
I
just
wanted
a
couple
couple
of
things:
I
want
to
call
out.
You
know
when
I
think
of,
like
my
iPhone
and
my
Android
phone,
you
know
that
that's
pretty
much
what
I
have
to
do
right,
I
have
to
export
my
contacts
from
one
phone
and
use
use
some
service
or
or
some
other
utility
to
import
on
my
other
phone
I.
B
Don't
really
expect
like
iCloud
and
I
suspect,
Apple's
iCloud
to
work
with
my
Google
phone
or
my
Google
contacts
to
work
with
my
iPhone
so
seems
pretty
equivalent
and
standard
in
the
industry
to
have
to
export
to
a
file
and
import
it
on
another
device.
On
the
on
the
caller
ID.
The
visual
caller
ID
is
more
than
a
picture
which
is
pretty
typical
and
standard
for
us.
It's
actually
a
pattern
of
lights
and
it's
something
that
we
do.
B
I,
don't
I
I,
don't
think
that
other
providers
do
it
exactly
the
same
and
I
think
we
and
we
do
actually
have
a
patent
on
that.
So
the
problem
is,
is
that
there
aren't
really
any
standards
defined
across
providers
for
how
some
of
those
things
are
done.
So
you
kind
of
end
up
with
kind
of
a
lowest
common
denominator
of
functionality
across
contacts
which
just
doesn't
seem
ideal
and
then
I
kinda
think
I
agree
with
what
Paul
was
saying
where
it's.
B
It
seems
odd
to
say
that
the
provider
has
to
then
provide
this
type
of
card
day
of
service,
or
it's
really
I
think
that's
up
to
whoever
the
room
provider
is
if
they
want
to
do
their
own
carddav
service
as
a
way
to
manage
contacts
across
devices
devices
that's
great,
but
it
doesn't
necessarily
make
sense
to
say
for
the
provider
that
the
providers
would
need
to
do
that.
Thanks.
A
A
We're
talking
about
a
j-card
which
is
extensible
and
already
has
a
large
list
of
attributes,
and
then
we're
talking
about
the
transport
mechanism
for
that
which
is
a
file
of
J
cards
or
a
sink
of
J
cards.
And
it
does
seem
to
me
that,
even
if
you
had
a
set
of
features
that
is,
you
had
a
set
of
user
characteristics
that
were
associated
with
a
contact
that
was
proprietary.
A
It's
a
question
of
whether
or
not
it's
a
good
idea
for
the
device
to
have
the
ability
to
manage
contacts
within
itself
and
have
the
ability
to
obtain
contacts
from
some
service
not
specified.
Who
runs
the
service.
It
just
says
the
device
that,
across
the
interface,
a
file
transfer
of
J
cards
and
the
carddav
interface
is
support
it,
and
it
seems
to
me
that,
though,
both
of
those
are
good
things
to
do,
it
doesn't
prohibit
you
from
extending
it.
It
doesn't
prohibit
you
from
saying
I,
don't
supply
the
service.
A
All
I
do
is
support
the
interface
across
it.
So
the
URI
that
you
provision,
which
is
your
card
dam
server,
doesn't
point
to
you
points
to
something
else.
That's
all
fine,
but
I
think
that
the
that
that
I
think
personally
think
that
it's
a
good
thing
for
the
ROO
to
have
to
support,
but
both
the
the
upload/download
and
the
and
the
sync
mechanisms
and
one
more
thing
and
then
then
I'll,
let
Adam
talk,
I,
actually
don't
upload
and
download
contacts
anymore
or
haven't
had
to
do
that
in
a
very
long
time.
A
G
Adam
Roach,
you
actually
covered
almost
everything
that
I've
got
up
here
to
say,
but
I
want
to
go
ahead
and
put
a
fine
point
on
three
specific
items.
The
first
is
that
the
J
card
and
and
B
card
format
specifically
has
ways
to
register
vendors.
Specific
extensions
for
things
like
proprietary
features.
The
second
is
this:
the
sync
text
journal
like
my
phone
right
now.
G
My
address
book
is
predominantly
stored
on
Yahoo
because
they
have
an
address
book
server
that
I
can
use
card
out
with
and
that,
thanks
to
my
other
non
apple
devices,
with
no
problems,
which
is
a
really
good,
real-life
example
of
exactly
what
you're
talking
about
the
third
thing
was
related
to
the
third
thing
you
said
and
I
can't
remember
what
it
was,
but
it
I
pretty
much
agree
with
everything
that
you
just
said.
Okay,.
C
H
C
A
A
Again,
happy
to
work
on
wording
to
make
sure
that
it's
it's
clear
that
that
it's
not
implying
that
any
particular
operator
is
running
any
particular
service.
It's
it's
just
that
the
interface
itself
supports
both
a
file
transfer
and
it's
you
know
it's
it's
web
retrieval
right.
It's
downloaded,
Jason,
a
large
JSON
objects,
not
really
a
file.
I
see
Paul
and
Isaac
Isaac
I.
B
H
H
It's
links
to
the
provider
somehow
whether
they
implement
it
or
do
it
by
referral
but
but
like
Adam
suggested.
It
may
be
that
the
user
wants
to
have
his
own
and
so
I'm
not
sure
how
it
fits
into
the
thing.
But
I
think
there
ought
to
be
a
mechanism
for
the
fruit
for
the
user
to
provide
a
place
to
sync
to
independent
what
the
provider
provides.
I.
A
Think
that's
an
excellent
idea,
and-
and
we
definitely
should
do
that
that
currently
it's
it
is
part
of
the
the
provisioning
but
I
think
that
that
ought
to
be
separately
provisional.
Because
if
you
like
your
contacts
coming
from
Google
instead
of
your
provider,
then
you
should
be
fully
entitled
to
do
exactly
that.
A
Okay,
so
now
is
the
big
question
of
what
do
we?
Don't
you
know
what
what
else
is
there?
If
you
know
we're
not
ready
to
call
for
last
call
on
the
document?
I
mean
we're
not
and
I'm
not
talking
about
that,
but
I
would
like
to
know
what
other
areas
of
the
document
people
think
need.
Neat
work.
What
what
where?
Where
are
there
things
that
it
currently
don't
currently
believe
it
is
in
the
state
that
it
needs
to
be
in
and
I'll?
You
know,
I
I
know
I've
kind
of
sprung.
A
That
can
be
small,
stuff
or
big
stuff,
but
I
am
you
know
we
started
out
with
a
pretty
good
draft.
We
brought
a
whole
bunch
of
issues
up
and
we're
working
on
those
issues.
I'd
like
to
know
what
other
issues
people
think
they
are.
They
that
exist
in
the
document
so
that
we
can
start
thinking
through
what
what
we
want
to
say.
So,
that's
as
I
say
it's
it's
more
of
a
plea
to
read
the
document
and
send
comments.
D
List
them
I'm
apologize
for
being
late
them,
possibly
mr.
discussion,
I'd
rather
draft
this
morning
and
I
found
a
number
of
occurrences
with
of
the
term
with
the
understanding
that
and
then
the
protocol
violation
and
I
would
like
to
have
the
well
the
behavior
that
was
intended
spelled
out,
rather
than
having
the
understanding
that
okay,
for
instance,.
D
And
there
was
mentioned
that
we
don't
use
media
stream
tracks
and
but
it
doesn't
say
what
do
you
mean
by
that,
so
that
if
you
instead
put
them
with
a,
but
we
are
not
going
to
send
the
MS
IDs
and
we
are
going
to
ignore
them
on
reception?
That's
fine,
I
mean
if
you
want
to
bake
the
standard,
say
exactly
exactly
how
you
should
behave
when
you
break
this
knowledge.
Okay,.
A
I
will
take
that
under
advisement
and
go
look
at
all
those
instances
in
and
try
and
come
up
with
good
worried.
You
know
I
may
contact
you
for
suggestions,
but
thank
you,
I
yeah,
that,
with
the
understanding
that
is
usually
not
good
standards,
language
and
I
wrote
that
so
I
should
you
know.
I
shouldn't
have
said
that
when
it.
H
A
That
very
there
is
no
text.
Currently
there
there
there
is
provisioning
of
a
certificate
for
the
purposes
of
doing
mutual
loss,
which
we
could
drop.
If
people
don't
want
it,
but
that
there
isn't
anything
the
the
piece
that's
still
there
is
the
call
info
header
that
tries
to
tell
you
who,
where
this
thing
came
from.
H
H
H
H
The
vent
manufacturers
of
devices
could
get
them
certified
and
then
they
would
get
us
assert
that
they
used
to
prove
that
their
device
had
been
certified,
that
the
providers
could
use
to
screen
out
uncertified
devices
from
that
you
know
disallow
them
from
being
connected
and,
frankly,
I
never
believed
that
mechanism
as
written
worked
and
yet
III
the
providers
have
a
desire
for
something
like
that.
I
don't
know
a
mechanism
that
would
work,
I
mean.
Obviously
we
have
things
you
know
like
phones,
you
know
that
they
have
certificates.
B
Isaac
you're
on
yeah
I,
agree,
I,
agree
with
Paul
I
think
this
is
definitely
a
big
concern,
something
that
we
definitely
do
need.
We
need
the
ability
to
protect
our
systems
from
hackers
or
anyone
that
might
get
their
hands
on
this
open
source
code
for
the
Roo
or
VT
RP
and
I
I
can
see
ways
that
it
could
work
where
it's
like.
B
You
know,
if,
if
I'm,
if
I
the
provider
in
the
one
building,
the
Roo
I
can
include
my
clients
cert,
which
I
only
have
the
private
key
for
and
so
that
I'm,
the
only
one.
That's
able
to
do
that
so
that,
when
that
client
connects
to
my
system,
I
know
that
as
it
has
been
tested
and
won't
cause
any
issues
on
my
system
that
could
affect
my
users
ability
to
communicate.
B
So
it's
absolutely
critical
that
we
have
some
mechanism
so
that
we
aren't
just
creating
this
open
door
for
anyone
to
connect
into
our
system,
which
is
not
typical,
I.
Think
the
example
that's
been
used
as
web
browsers,
right
and
web
browsers
are
another
place
that
you
might
use
a
client
cert.
So
so
you
know
my
bank
could
do
that.
My
bank
could
say:
hey
look
here.
B
Here's
a
client
certificate
install
this
on
your
browser,
and
this
will
ensure
that
you're,
the
only
one
that
can
access
your
account,
it
frankly
hasn't
been
used
because
it's
it's
difficult
right
from
from
a
user
perspective,
to
have
to
get
a
certificate
and
understand
how
to
install
that
and
so
I
think
the
example
that
was
given
was
that
well
any
you
know,
web
browsers
are
open
source.
Anyone
can
go
get
that
code
and
they
can
go
and
connect
to
any
web
server,
and
this
is
just
the
same
as
that.
B
But
it's
not
the
same
because
it's
our
communication
system
or
the
phone
company
for
the
Deaf
and
we
really
have
to
protect
our
system
and
our
users
from
any
hacker
or
various
actors
that
might
want
to
do
them
harm.
So
it's
absolutely
critical
that
we
have
saying
I
didn't
even
I
had
a
notice
that
had
been
removed
from
the
latest
version.
A
Written
right
now,
all
it
says,
is
during
the
establishment
of
a
secure
connection
with
the
provider
of
the
room
may
be
asked
by
the
server
for
a
client
certificate.
In
this
case,
it
should
provide
the
provisioned
client
certificate,
see
section.
9.2
riders
may
reject
requests
that
fail
to
provide
a
recognized
certificate.
That's
what
it
currently
says
it
is
there.
H
D
A
B
You're
right
you're
right
so
does
there
I
see
that
now
and
I
think
that
the
example
that
Paul
gave
previously
was
almost
something
like
an
app
store
right,
like
as
as
an
as
an
iPhone
developer
or
I,
submit
my
ad
to
Apple.
They
tested
they
verify
it
works
okay
and
then
they
make
it
available
on
their
App
Store
for
any
user
to
to
download
and
use
on
their
phone.
B
I
C
All
right,
I
guess:
athletics,
I,
just
on
the
certificate
thing
I
mean
the
reason
why
Apple
is
able
to
sign
things
in
the
App
Store
is
they
sign
the
entire
app,
whereas
this
you're
not
uploading
your
entire
Ruth
software
to
the
provider,
so
the
provider
is
no
guarantee
that
the
Ruth
software
hasn't
been
modified
or
indeed
that
somebody
hasn't
just
extracted
a
certificate
from
one.
You
know
piece
of
Roo
software
and
using
it
in
their
own.
C
You
know
that
allows
it
allowed
to
connect
to
the
system
and
that
you
know
deaf
and
hard-of-hearing
users
can't
you
know,
do
their
own
development
of
their
own
endpoint
and
make
their
own
enhancements
feels
like
it's
kind
of
locking
down
the
system
more
than
I
would
like
mm-hmm
I,
think
you
know
in
general,
if
you're
running
a
service
on
the
internet,
you
have
to
be
have
some
way
of
protecting
from.
You
know
crazy.
You
know
from
something
you
know:
attacking
your
internet
and
I
think
the
protection
here
is,
you
know
what
you
actually
have.
C
Is
you
don't
know
the
endpoints
offer?
You
know
the
person
and
if
the,
if
you
have
a
user
name
and
password,
that's
attacking
you.
Well,
you
can
say
we're
shutting
down
this
person
because
they're
not
behaving
legitimately
they're.
You
know
they're
screwing
with
our
system,
so
send
so
you
know
block
them
out
until
we
figure
out
what's
going
on.
A
Yeah,
that's
that's
kind
of
my
thinking
that
that
I
don't
know
a
way
to
protect
a
piece
of
downloadable
software
from
modification
by
any
number
of
tools
or
extracting
the
certificate
out
of
that
code
and
and
using
that
as
a
way
to
protect
the
other
end.
As
from
from
malignant
software.
We
you
basically
can't
do
that.
We
don't
know
how
to
do
that
and
and
that
we
there
just
isn't
that
just
that
mechanism
just
doesn't
work.
G
Adam
Rhodes
I
wanted
to
put
a
finer
point
on
it's,
not
just
that.
We
don't
know
how
to
do
that
as
we
don't
need
to
do
that,
because
we
have
a
really
good
proof
of
existence
of
a
system
that
that
handles
this.
Just
fine
mobile
phones,
right
I,
can
take
my
sim
out
of
my
phone
and
put
it
in
any
other
phone
without
any
validation
to
what
the
implementation
of
that
phone
has
done.
G
You
can
get
like
cheap,
weird
phones
from
all
over
the
world
that
do
heaven
knows
what,
and
as
long
as
I'm
able
to
authenticate
it
goes
into
the
system
and
it's
the
same
sort
of
setup
right.
If
I
put
it
my
sim
into
a
phone
that
starts
attacking
the
network,
they're
gonna
turn
off
my
access
and
the
system
is
pretty
well
protected.
This
doesn't
generally
happen,
but
you
know
in
theory.
It
could
and
I
think
that
engineering
anything
more
advanced
than
that
is
probably
unnecessary.
D
B
Up
yeah
well
like
a
SIM
card,
would
be
great
right.
A
SIM
card
provides
a
physical
hardware
ID
that
allows
me
to
verify
that
that
is
my
user.
So
I
don't
think.
That's
that's
a
good
equivalent.
The
type
of
attack
we'd
be
worried
about
would
be
like
a
brute-force
attack.
So
let's
say
I
know
my
ex-girlfriends
phone
number
and
now
I
can
go
get
the
open
source
code
and
I
can
fairly
easily
write
a
script
that
can
just
boot.
Brute-Force
attack
the
system
to
figure
out
what
the
password
for
that
user
is.
B
If
I'm
just
doing
a
brute-force
attack
like
that,
then
I
don't
know
who
that
user
is
and
I
can't
necessarily
just
cut
them
off
and
then,
but
again,
something
like
a
SIM
card
would
be
a
great
solution.
I
just
don't
know
what
the
equivalent
is
for
a
software
app
that
doesn't
involve
an
actual
device.
I
know
there
are
like
Isom
cards
on
like
Google
phones,
but
I,
don't
I
think
they'll
still
depend
on
a
chip
or
mechanism
within
the
actual
device
to
make
that
possible.
H
G
In
terms
of
mobile
phones,
they
we
do
have
soft
sims,
where
these
are
things
that
can
be
pushed
out,
that
you
don't
have
to
have
physical
devices
that
represent
these
and
they're,
basically
certificates
and
so
yeah.
The
answer
for
how
you
do
this
in
software's
certificates
right,
you
can't
brute-force
a
search.
It's
your
yeah!
It's
not
like!
You
can
do
this
sort
of
credential
stuffing
the
you
would
if
you
were
validating
with
passwords
and.
G
A
H
H
The
best
thing
I've
thought
of
that
that
I
could
imagine
could
work
here
is
that
the
provisioning
server
would
somehow
run
a
self-test
or
something
on
the
device
that
satisfy
itself
that
the
device
was
acceptable
before
provisioning
it
or
something
like
that,
and
then
it
can
provide
the
cert,
but
at
the
end
of
the
day
it
would
be
it
I
mean
it
would
probably
be
a
client
cert.
You
know,
and.
H
This
is
a
mechanism,
that's
that's
different
than
what
the
providers
had
originally
imagined
when,
when
the
stuck
was
originally
written
into
the
respec,
if
we
can
determine
that
that
and
because
the
original
one
was
on
a
per
application
basis,
if
you
will,
you
know
and
I,
don't
know
how
to
make
that
work.
But
if,
if
something
like,
this
can
be
shown
to
be
to
meet
the
providers
needs,
then
maybe
we
have
a
solution.
All
right,
I
think
we
just
have
to
discuss
it
on
the
with
all.
A
A
I
One
question
I
have
I'm,
not
sure
if
this
has
been
discussed
is
with
regards
to
9-1-1
and
provisioning
the
user.
This
is
all
from
the
arrests
respect.
You
know
how.
How
does
the
person
indicate
their
death
and
we're
able
to
provision
their
home
address
for
use
with
9-1-1
services,
and
are
we
going
to
be
passing?
X
Y
coordinates
to
be
able
to
service
their
91.
One
calls
faster.
A
A
But
what
this
the
text
currently
says
that
the
the
ROO
device
has
to
support
68
81,
and
that
means
that
it
can
supply
an
address
or
the
address
can
be
supplied
by
the
provider
that
handles
the
call
on
its
way
towards
the
9-1-1
service.
It
means
that
you
can
support
3-way
video
with
the
bridge
at
the
at
the
peace
app
the
9-1-1
call
center.
A
I
A
Don't
currently
have
any
support
as
far
as
I
know,
none
of
the
providers
currently
have
any
support
for
next
gen
9
1
1.
You
currently
use
the
eye
2
mechanisms
which
are
void,
mechanisms
to
the
current
inai
non
1
system,
which
are
different
in
every
way
from
how
the
next
generation
9
1
1
works.
The
text
is
not
clear
and
could
be
made
clearer
about
whether
the
device
can
supply
location
and
how,
if
it
did
how
it
is
verified
and
I.
A
Think
that
that
your
that
that
prompts
me
to
write
a
note
in
the
notes
that
says
we
should
clarify
that
in
the
in
the
document
as
a
practical
matter,
although
the
ITF
doesn't
like
it
the
way
it's
being
deployed,
the
location
is
supplied
by
the
provider
or
the
the
the
network
operator.
The
the
the
thing
that
provides
the
calling
service
it
would
be
the
VoIP
provider
in
the
case
of
a
VoIP
device
rather
than
the
end
device.
A
I
Our
our
provider
on
that
we
supply
XY,
coordinates
to
our
provider,
but
they
require
before
they'll
use.
Those
XY
coordinates
that
there
is
a
physical
address
already
assigned
to
that
that
person,
yeah
and
they'll
only
use
the
XY
coordinates.
If,
if
that
person
has
been
quote
quote
validated
or
registered
with
them,
yeah.
A
I
I
understand
what
you're
talking
about
I
know
all
about
these
mechanisms,
so
the
standards
that
are
referred
to
in
the
current
document
support
either
XY
X,
X,
Y,
Z
or
or
Civic,
or
both
and
and
again
we
could
clarify
in
the
text
whether
or
not
the
device
has
to
be
able
to
be
provisioned
with
its
location
or
whether
it
can
supply
X
Y.
We
can
there
there's
insufficient
text
on
that
subject
and
I
will
I
will.
I
A
A
A
Okay,
but
that
was
a
good
Steve.
Thank
you
for
bringing
it
up.
That,
clearly,
is
something
we
need
to
improve
and
I
was
kind
of
aware
of
that.
We
also
probably
could
spill
a
few
words
about
how
how
the
current
document
only
describes
the
existing
system
I'm.
Sorry,
the
next
generation
9
1
1.
It
doesn't
really
talk
about
the
existing
system.
The
device
doesn't
have
to
do
anything
for
the
existing
system,
so
that
that
doesn't
mean
anything,
but
we
could
say
that
and
then
it
would
be
clear.
B
A
If
you
want
that
provisioned
in
that,
that
would
be
fine.
Typically,
what
almost
every
service
I
know
about
does
for
that
is
is
a
web
page
I
mean
that
is
how
vonage
does
it
it's
not
in
the
phone?
It's
not
in
anything
that
that
is,
it
is
in
the
inning
and
any
interface,
it's
literally
a
web
page.
So
if
you
want
something
beyond
that,
I
mean
I'm
happy
to
put
that
in
it
doesn't
isn't
the
problem
to
do
that.
Yeah.
G
Just
Adam
Roach,
you
might
want
to
give
some
thought
when
you
do
that
about
exactly
how
it's
going
to
interact
with
authentication,
given
that
users
are
authenticated
in
the
system
right
now
by
certificates
and
you're
not
going
to
get
that
on
the
webpage
side
of
things
makes
things
a
little
bit
more
interesting,
so
yeah
we
might
actually
look
at
leveraging
the
sip
signaling
information
to
convey
this
information
to
the
carrier
in
some
way.
Okay
I
was
writing
member.
A
C
L
Hi
I,
you
mentioned
that
for
the
emergency
call
you
need,
you
will
get
video
on
multi-party
view.
You
know
we
have
a
discussion
going
on
for
multi-party
real-time
text.
Well,
you
need
that
as
well.
I
think
you
would
all
right.
Maybe
I
should
just
draw
attention
to
what
we
are
starting
up
in
abt
core.
G
M
A
A
A
A
A
A
A
A
What
time
is
it
for
you?
It
must
be
really
awful,
but
I
appreciate
your
participation.
It's
been
great,
having
you
on
participating
in
it
in
the
meeting
and
I
hope
we'll
be
generating
a
lot
of
lifts
traffic
as
a
result
of
all
these
discussions,
which
is
always
what
we
want
to
see
and
unless
there's
anything
else,
I
think
we're
adjourned.