►
From YouTube: IETF105-RUM-20190723-1520
Description
RUM meeting session at IETF105
2019/07/23 1520
https://datatracker.ietf.org/meeting/105/proceedings/
B
C
F
F
B
This
is
ROM.
If
that
isn't
your
drink
of
choice,
you
could
find
another
another
fine
room.
There's
plenty
of
rooms
to
choose
from
we
do
have
I
do
remind
you
that
there
we
have
quite
a
few
participants
that
are
remote,
Omnitech
Oh.
So
please
do
use
the
microphone
carefully,
because
those
people
who
are
not
in
the
room
can't
hear
you
shouting
across
the
room.
B
B
We're
we're
it's
still
just
Tuesday,
so
not
everybody
knows
what
note
well
is
again
everybody
in
the
room
does,
but,
but
for
those
of
you
who
are
new
to
the
ITF
process,
you
really
do
need
to
sure
that
you
understand
the
the
meaning
of
the
ITF
note.
Well,
this
is
all
yeah.
It's
it's!
It's
all.
How
did
that
work
there
we
go.
B
B
B
Hennig
is
going
to
spend
a
little
time
talking
about
other
documents
that
are
relevant
to
the
work
that
we
are
doing
and
and
maybe
guideposts
for
things
that
we
want
to
take
into
account
as
we
go
through
our
work.
There
is
a
draft
draft
Rose
Andrew
oo,
which
I
will
present,
and
then
we
have
an
open
discussion.
G
Is
very
appropriate,
the
Internet
Society,
it's
got
a
bunch
of
policy
makers
coming
in.
One
of
the
things
we
talked
about
was
how
governments-
and
this
is
one
of
those
times-
that
we
have
a
situation
out
there
where
there's
a
service.
That's
been
running,
so
we're
not
experimenting.
It's
not
a
science
project
and
that
particular
application
is
video
interpretation
for
deaf
and
hard
of
hearing.
So
it's
a
relay
service
during
person
calls
definitely
user
and
that
call
gets
routed
if
your
mic
is
off.
G
G
We
think
the
time
is
right
to
come
up
with
a
standard
interface
and
a
globally
standard
interface,
because
these
are
services
that
are
not
limited
to
the
United
States.
There
are
other
countries
that
would
like
to
offer
similar
services,
and
you
can
imagine
the
protocol
mechanisms
actually
could
be
useful
for
other
scenarios.
B
H
Here,
can
you
hear
me
now
yeah
there
you
go,
okay,
I
know
I'm,
not
pitching
or
isn't.
So
let
me
give
you
a
little
bit
of
history
based
on
what
Eric
was
starting
to
talk
about.
Not
so
next
slide,
please
so
for
most
of
you
are,
this
is
old
news
and
I
see
there
number
of
people
on
the
call
are
in
the
remote
participation,
probably
a
much
better
qualified
to
talk
about
it
and
I
am
but
I
will
try
and
I'm
sure
they
will
correct
me
if
I
were
to
make
a
mistake.
H
So
we
use
scenario
that
we've
been
dealing
with
a
number
of
years.
Really
is
our
video
relay
our
services,
which
consists
typically
I
in
its
classical
form
of
two
models,
namely
one
is
one
shown
on
the
slide
where
you
have
a
death
or
speech
impaired
in
some
cases,
user
who
wants
to
communicate
with
a
healing
only.
E
H
A
classical
phone
I'm
aria
only
device
and
does
not
converse
in
sign
language.
The
diffuser
in
an
outbound
call
a
contacts
service
provider
that
they
have
subscribed
to
you
and
then
that
in
turn,
wings
up
a
hearing
person,
the
interpreter
act
as
a
human
media,
translator
between
ESL
sign
private
diffuser,
captured
by
a
camera
which
is
then
relayed
in
voice,
open,
live
interpreter
to
be
hearing
persons
and
vice
versa,
of
a
hearing
person's
voice
is
conveyed
in
assigned
interpretation
of
the
to
build
a
future
on
a
video
screen.
I.
H
This
is
been
like
I
said
around,
for
it's
somebody,
gonna
be
precise
date,
but
more
than
a
decade,
certainly
probably
twenty
years
in
one
form
started
out
in
a
323i
and
and
in
devices
that
you
attached
to
a
television
set
and
then
now
looks
very
much
like
a
commercial
video
conferencing
and
indeed,
in
many
cases,
is
do
I'm,
a
commercial
you're
conferencing
product
with
some
RPC
type
of
model.
A
next
slide,
please
I,
will
point
out.
This
is
not
directly
relevant
to
run,
but
it
does,
and
aquavit
to
some
extent
is
I
mean
us.
H
Video
services,
video
relay
services,
use
two
databases,
one
which
are
familiar
database
technology-
that
probably
one
could
argue,
probably
has
the
largest
use
in
video
relay
service
after
it
is
not
quite
caught
fire
elsewhere,
namely
enum.
So
there
is
an
enum
database,
a
traditional
10-digit
telephone
number
to
a
gateway
address,
which
is
then
service,
but
a
subscriber
or
not,
so
that
all
the
video
relay
service
providers
used
out
as
a
mechanism
to
figure
out
where
to
send
Bishop
caller.
H
In
the
old
days
the
H
was
recalled
or
not
more
recently,
there
is
established
for
a
variety
of
management
purposes,
primarily
to
establish
eligibility.
The
program
has
had
a
history
of
fraud
and
other
issues
that
have
occurred.
Surveys
the
concern,
given
the
high
cost
of
providing
the
service
at
only
eligible
users.
Users
anyway,
said
accountable
surveys,
a
user
registration
database
that
uses
an
HTTP
Jason
style
query
model
in
a
papaya
completely
proprietary.
This,
unfortunately,
is
not
modern
I.
H
Why
to
bind
a
telephone
number
to
essentially
my
natal
URL,
as
well
as
some
management
related
information,
eligibility
and
so
on.
Why
not
I'm
next
slide,
please
one
important
part
and
Eric
I
think
alluded
to
that
in
one
aspect,
namely
that
what
we
talked
about
in
Malawi,
really
just
while
motivated
I
believe
relay
service.
There
are
actually
three
different
major
services
that
I
used
by
people
who
are
deaf
or
hard
of
hearing
and
need
communication
assistance,
namely
a
video
relay
modeled.
H
It
is
focus
of
our
discussion
here,
I
various
forms
of
text
we
lay
and
I,
what's
known
as
caption
telephone
service,
IPC,
yes
I,
doubt
Eggman's
a
telephone
call
by
a
human
at
moment,
mostly
human
generated
speech,
to
text
a
rendition
can
be
used
by
a
person
who
can
speak.
I
has
in
audio
as
well
as
one
needs
assistant,
understanding
the
other
side
beyond
audio
call.
What
I
want
to
point
out
for
one
purposes.
H
H
H
So
they
are
people
who
use
that
as
a
as
a
number
based
on
universally
available,
as
in
there's
a
expectation
that
everybody
in
the
United
States
has
at
least
potentially
access
to
video
relay
service.
We
and
if
you
know,
that
person's
telephone
number,
you
can
now
converse
with
that
person
without
having
to
worry,
but
we're
using
whatsapp
or
FaceTime
or
Skype
or
I
want
every
half
dozen
different
Google
options
or
whatever
else
they
might
use.
H
So
there's
a
point-to-point
mode
as
well
as
a
relayed
mode
in
that,
and
so,
but
in
general,
all
of
the
relay
services
and
just
to
some
extent,
I
think,
should
inform
our
discussions
going
forward.
It
is
would
be
quite
useful
if
some
of
these
other
relay
services
could
also
use
the
same
technology
I
again.
That
offers
new
opportunities
for
new
services.
We
currently
don't
can't
easily
offer
because
miss
stovepipes
next
slide,
please
I
again.
This
is
a
short
version
of
how
a
car
works.
H
It's
very
much
for
anybody
in
the
subdomain
vain
familiar
is
typically
providers
I
doubt
a
connected
to
each
other,
kept
by
my
eye
beam
on
the
internet.
Generally,
they
don't
as
far
as
I
know.
Typically,
don't
do
private
peeling
eye,
but
they
establish
a
secure
tunnel
of
some
sort
and
they
query
database
which
operated
I
knew
stored
and
we
turns
except
domain
that
returns.
A
second
bite-
and
we
I
was
so
it
looks
very
much
like
a
inter
provider
so
call
to
all
of
us
next
slide,
please.
H
So
what
is
the
recurring
problems
that
motivate
this
particular
work?
I
for
many
years,
I
we've
had
really
two
problems.
One
initially
was
that
it
was
difficult
on
at
reasonable
quality
to
make
calls
between
providers
and
in
the
United
States
in
particular,
we
have
a
situation
where
we
have
one
Bay
large
provider
that
has
somewhere
around
eighty
percent
market
share
in
a
number
of
smaller
providers,
divide,
remainder,
I,
sometimes,
users,
multiple
providers,
for
any
number
of
reasons,
I
and
like
in
any
amend
I.
H
There
is
a
challenge
initially
to
provide
interoperability,
particularly
at
equivalent
video
quality,
as
in
you
might
get
better
quality.
If
true,
if
the
two
participants
in
the
call
particular
for
point-to-point
calls
were
using
the
same
provider
versus
local
item
and
not
that
problem,
as
was
alluded
to
be
interoperability
test,
seems
to
be
largely
solved.
I
worry
some
prodding
by
the
FCC
along
the
way
to
make
everybody
play
nice
or
at
least
pretend
to
play
nice
I'm,
and
what
is
remaining
problem
that
LOM
addresses
is
the
ability
to
take
a
usually
and
among
services.
H
So
what
you
might
call
device
supporting
our
part.
We
leave
software
in
many
cases
these
days,
not
a
physical
device
I
in,
namely
a
user
and
operability.
Currently
every
service,
even
though
they're
often
based
on
SEP,
often
using
fairly
familiar
technology,
that
we
all
have
seen
that
a
standards-based
at
least
mostly.
H
You
cannot
take
a
device
that
you
acquired
through
provider,
a
to
provider
B,
if
you
happen
to
use
two
providers,
you
you
have
to
use
two
pieces
of
software,
just
like
we
face
member
says:
what's
up
that
one
I,
so
that
software
is
currently
provided
for
free
and
I,
put
that
intentionally
in
quotation
marks,
because
it
is
free
to
be
user.
But
as
I
mentioned,
this
is
a
subsidized
service
of
a
service
which
is
provided
by
a
mine.
H
They
pay
us,
like
you
I,
at
least
if
you
are
in
the
United
States
I
to
VLS
users,
and
so
the
cost
of
equipment
is
a
stripling,
a
small
fraction
about
as
well
I'm.
We
have
an
idea
that
motivates
I
money
is,
is
a
small
market
if
my
recollection
is
collect
and
Eric
and
time
in
were
more
up
to
or
correct
numbers.
C
H
H
People
want
to
switch
providers
on
a
call
by
call
basis,
so
this
could
be
because
calls
fail
I
evil,
because
their
long
wait
times.
This
is
humans
and
versus
effectivity.
So
you
might
have
to
wait
while
to
get
a
call
I
interpret
interpreter
people
might
want
to
try
some
other
service
or
just
because
they're
failures,
as
in
kind
of
my
version
of
that
I,
probable
cause
and
also
people
have
multiple
numbers
for
incoming
calls
for
any
number
of
reasons
again.
H
I
think
the
ability
to
try
out
new
services
whatever
and
they
would
it
would
be
nice
to
have
at
all
coming
in
on
one
device
as
well.
Ok,
next
slide,
please
ok,
the
sorry
for
interoperability.
Cake
version
are
in
not
so
we
have
the
basis
a
plate,
namely
we
need
to
unite
and
I,
find
we'll
talk
about
those
in
detail.
I
will
have
the
vagus
sip
options
that
need
to
be
defined.
I
clearly
have
to
deal
with.
H
Media
types
are
in
the
middle,
then
it
gets
a
little
more
in
the
past
at
least
contentious
as
to
whether
that
should
be
part
of
it
not,
and
these
are
things
that
have
fall
outside.
In
many
cases,
I
could
have
standard
voice
of
IP
enterprise
text,
I,
NAT
aversive
really
doesn't
on,
but
configuration
retrieval.
As
we
all
know,
we've
never
managed
to
create
standardized
sip
configuration
to
do
anybody
actually
uses
I
ng
namma.
H
One
number
one
calls
a
mandatory
to
support
feature
for
every
service
that
offers
video
relay
services
and
I'm
so
then
and
I
portray
on
top.
Are
then
services
like
video
and
voice
mail,
that
of
a
common,
putting
a
video
mail
for
the
relay
I
address
the
portability
I
want
to
be
able
to
port
my
address
book
across
services
to
avoid
capture
and
things
like
speed,
owl
and
severe
a
number
of
services
that
have
become
common
but
I,
currently
tied
to
a
provider
next
slide.
Please
so
I
won't
go
through
that
in
great
detail.
I
it's!
H
This
is
an
incomplete
timeline
and
I
to
in
some
extent,
because
I
I
don't
have
the
precise
stage.
So
don't
take
this
too
literally
I,
but
I
generally,
we've
tried
for
roughly
seven
years
now
are
to
work
on
this
problem.
We
collectively
when
people
who
have
been
interested
in
video
relay
service.
So
one
of
the
first
attempts
that
started
I
believe
roughly
in
September,
2012
I,
accept
form
actually
created
a
task
group.
I
Dodd
addressed
to
problems
but
ended,
actually
only
being
one
of
us,
the
FCC
had
a
major
document
codified.
H
Some
of
these
interoperability
issues,
mitre
got
involved
eyeing
as
well.
An
inbound
call
on
one
of
the
participants,
I
nod
I
a
contract
was
led
to
a
company
called
BTC
secure
to
build
a
prototype,
a
production
system
for
what
it
was
called:
data,
p.I,
video
access
telephony
reference
platform,
I,
a
visit
forum
published
a
provider's
profile
for
interoperability
between
providers,
which
has
been
with
subject
of
easy
interoperability,
tests
that
Eric
mentioned
earlier
and
that
I
might
or
has
been
taking
a
much
more
active
lead
in
this
particular
effort.
H
H
There
is
a
separate
effort
that
actually
attracted
a
number
of
people
interested
in
video
relay,
but
is
not
meant
to
was
not
meant
to
be
exclusive
to
that,
namely
called
the
interoperable
video
calling
group
as
part
of
a
North
American
Numbering
Council.
A
report
for
that
group
is
pending.
But
if
you're
interested
in
that
you
can.
H
H
We
in
Taupo
were
really
calling
group
one
particular
aspect
as
far
as
I
can
tell,
and
you
know
it
may
or
may
not
be
at
liberty
to
discuss
what
real
I
mean.
What
a
real
motivation
was
is
used
to
please
for
more
video.
You
know.
Stud
was
not,
which
we
anticipated
is
communication
between
people
who
are
otherwise
not
eligible
for
relay
and
see.
If
we
connected
lost
connection.
I
I
H
Me
see
now
I'm
back
yeah,
I'm,
sorry
about
that,
I,
don't
think
it's
my
problem,
because
I
have
an
on
average
10,
gigabit
connection
to
the
Internet.
So
in
any
event,
I
we
see.
One
of
the
use
cases
that
was
brought
up
is
that
there
are
a
number
of
entities
now
that
are
not
eligible
for
I
use
of
video
relay
service,
namely
people
who
are
hearing
but
speak
ASL
Eva,
because
there
are
friends
or
relatives
I
or
teachers
or
whatever
people
who
are
deaf
or
in
it.
H
But
many
of
us
our
call
center
type
applications,
so
ROM
in
particular,
is
likely-
and
this
goes
back
to
the
alternate
platforms-
is
particularly
useful
for
those
type
of
scenarios.
Namely,
we
are.
The
end
system
is
not
in
a
home,
but
it's
actually
in
a
dying
call
center
for
Comcast
or
I
mine,
so
it
like
I,
said,
be
a
Medicare
or
something
like
that.
H
We
are
those
calls
get
handled
and
they
need
to
be
integrated
into
a
call
outing
system
into
an
IVR
type
of
system
to
make
that
integration
feasible,
and
my
two
in
particular
has
been
working
on
some
prototypes
in
that
and
I
believe,
there's
some
initial
implementations
in
practice
actually
of
direct
video
calling.
Okay
next
slide.
Please.
H
H
And
this
is
just
for
reference.
This
was
the
original
charter.
I
don't
want
to
belabor.
It
simply
indicates
that
I
rum
is
essentially
in
one
like
completing
a
charter
that
we
did.
Support.
Sip
form
did
not
quite
complete
in
2012
because
it
deals
wavy
I
user
agent
as
well.
Next
slide,
please
again.
This
is
just
for
reference
to
illustrate
the
tasers
interoperability
profile.
I'm
again,
mostly
for
people
haven't,
looked
at
it
I
and
clearly
what
we
want
to
do
should
be
compatible
with
that
I'm
next
slide.
Please
I!
We
video
relay
service
interoperability.
H
There
are
a
number
of
related
efforts
ongoing
as
in
related,
broadly
speaking,
a
system
level
operability.
Interoperability
profiles,
mostly
for
carriers
and
PBX
is
most
of
us,
are
from
I
worship,
connect,
I,
specified
exit
features
and
codecs
done
days.
The
IP,
n
and
I
add
as
IP
n
and
I
for
voice.
I
doc
says
they
expect
that
I'm
not
a
familiar
way.
Y
bar
you
see
clearly
has
codecs,
and-
and
this
is
probably
one
that
many
of
us
are
not
as
familiar
whoa
and
I-
admit.
H
Lack
of
familiarity
until
I
did
a
little
bit
of
digging
and
I'm
still,
not
quite
sure
and
I
fully
understand
it.
So
CSV,
which
communication
system
not
now
I,
seems
to
get
some
traction
I
because
of
one
large
vendor
of
handset
software
I
dug
is
you
has
a
number
of
interoperability
profiles,
government
of
voice
and
video,
and
they
have
been
evolving
relatively
quickly
as
in
I've,
seen
versions
that
are
just
a
few
months.
Old
I
seem
to
be
much
more
fleshed
out
and
I.
H
Remember
seeing
I'm
so
there's
a
bunch
of
profiles
indicate,
for
example,
set
options
in
the
early
media
and
all
the
stuff
that
you
see
on
the
right-hand
side
when
I
copy
pasted
the
table
of
contents
of
one
particular
effort,
namely
for
video
vio
9404,
although
specs
are
publicly
accessible.
I
didn't
have
to
do
anything
special
to
get
that,
so
it
seems
like
that's
another
source
of
related
information
that
would
be
helpful
to
consider
it
would
be
mine.
This
is
my
editorial.
H
It
would
be
nice
if
it
wouldn't
be
too
difficult
to
bridge
between
the
rum
world
and
the
LCS
world,
even
if
they're
not
bit
compatible,
but
if
at
least
Gateway
a
ball
without
doing
media
translations
or
about
having
to
munch
call
flowers
too
much
in
that
that's
all
I
had
and
that's
great
any
discussion.
Questions.
B
There's
this
draft
out
there
that
was
put
out
to
start
discussion
of
this
work
group
and
and
I'm
working
on
an
update
to
it,
which
I
hope
actually
I
will
have
out
before
the
meeting
is
over
I
wanted
to
talk
about
what's
in
there.
This
is
mainly
a
table
of
contents
discussion,
rather
than
the
detailed
stuff
I
asked
you
to
read
the
the
draft
and
comment
on
it.
B
I
did
get
some
comets
from
Ollie,
which
I
very
much
appreciate
and
I'm
going
to
incorporate
all
that
I
can
of
that
into
this
next
version
and
start
discussion
on
the
few
items
that
I
wasn't
exactly
sure
how
exactly
we
wanted
to
handle
it,
but
if
others
could
could
read
the
draft
and
think
see
whether
what
they
think
of
it,
that
would
be
really
great.
So
the
top
level
table
of
requirements
go
into
some
generic
requirements.
It
just
lists
it's
basically
The
Hitchhiker's,
Guide
stuff.
B
You
must
do
all
of
these
are
C's,
there's
a
section
on
signaling,
which
includes
creating
a
call,
mid,
call
stuff,
ending
a
call
that
kind
of
stuff
there's
a
section
on
media
which
currently
has
specific
guidelines
in
the
new
version.
It
will
reference
the
web
RTC
media
specs.
That's
one
of
the
things
I'm
doing
the
SRT
P&S
rtcp
things
are
there,
which
also
probably
will
get
subsumed.
B
So
the
sip
signaling
includes
a
registration
session
establishment
with
normal
calls,
there's
something
that's
specific
for
VRS
in
there.
That
has
to
do
with
having
a
video
endpoint
connected
to
one
provider
and
then
using
another
provider
for
a
particular
call
for
that.
To
use
their
interpreters
for
a
particular
call,
that's
called
dial
round
and
there's
discussion
in
there
about
short-circuits
signaling.
For
that,
there's
how
you
specify
from
in
to
section
on
incoming
calls
and
a
section
on
emergency
calls,
there's
mid
call
signaling,
which
is
very
short,
doesn't
really
say.
B
A
whole
lot
says
you
got
to
handle
refer
and
a
couple
of
other
things.
It
has
a
section
on
exactly
how
we
handle
phone
numbers
and
has
the
section
on
unnatural
versal,
which
says
don
turn
and
again,
we'll
probably
make
sure
that
we're
in
in
compliance
with
whatever
exactly
web
RTC
says
on
that
the
media
section
as
I
said
currently
gets
into
specifics,
but
it'll
probably
get
display
replaced,
but
it
does
cover
real-time
text.
Rfc
4103,
real-time
text,
video
currently
uses
h.264
audio,
currently
says
711.
With
a
couple
of
other
options.
B
You've
got
to
deal
with
features
packet
loss
indicator
and
it
meant
specifically
for
video,
full
intra-frame
request
features.
So
there's
currently
text
there
once
again
probably
be
impacted
by
the
WebRTC
specs,
which
have
equivalent
mechanisms,
but
that's
what's
in
that
current
one.
In
the
contacts
section
in
the
current
document,
it
actually
describes
two
mechanisms.
One
is
a
file
based
upload
and
download
of
of
j-card,
and
then
it
uses
carddav
to
do
a
sync
of
those
functions.
B
B
So
we
get
to
decide
whether
we
want
to
use
this
document
as
a
basis
for
our
work.
We
get
to
decide
of
that
which
sections
we
want
to
keep
in
which
we
want
to
change,
and-
and
so
this
is
just
a
draft,
it
has
no
special
significance,
but
it
does
really
introduce
the
kind
of
ideas
that
we
have
and
I
will
put
out
a
as
I,
say,
I'm,
going
to
put
out
a
revision,
incorporating
the
comments
and
including
the
at
least
the
first
pass
of
WebRTC
references.
B
So
that's
that's
where
we
are
and
as
I
say,
you
can
expect
to
see
this
revision
of
the
document,
hopefully
before
the
end
of
this
week,
I
get
enough
time
and
don't
have
any
other
things
in
the
way.
But
I
really
would
appreciate
any
other
reviews.
People
want
to
do
in
the
current
document,
which
I
will
incorporate
in
the
next
version.
That'd
be
helpful,
but
otherwise
that's
that's
where
we
are
thanks.
John.
K
K
B
Issue,
thank
you
for
bringing
that
up.
So
actually
there
is
a
spec,
but
it
says,
use
the
data
channel
and
that
would
really
be
an
issue
for
backwards
compatibility
with
existing
devices
and
forwards
compatibility
with
devices
that
are
not
specifically
WebRTC
we're
talking
about
real-time
text,
which
is
not
a
high
data
rate
issue,
so
the
notion
of
transcoding
from
one
form
of
it
to
another,
is
not
an
onerous
task.
I.
B
Personally,
just
again,
this
is
my
personal
hat
on
been
working
on
this
for
a
while.
My
personal
hat
says:
do
the
standard
sip
RTP
based
4103,
not
the
WebRTC
in
the
data
channel
4104
real-time
text,
so
that
would
be
my
intention
for
that.
Does
anybody
implement
the
real-time
text
over
data
channel
in
the
I?
Don't
know
if
anybody's
done
it
yet.
I
I
B
I
So
I
think
that
the
right
decision
is
going
with
the
SIP
approach,
your
point
about
transcoding
being
very
cheap
as
a
salient
one,
and
perhaps
there
can
be
you
know
some
interest
fostered
in
putting
these
things
speaking,
no
hats
whatsoever,
not
even
you
know,
related
my
employer,
but
perhaps
there
can
be
some
interest
fostered
in
implementing
this
sort
of
thing
if
it's
a
straightforward
application
and
gets
relatively
well
deployed,
yeah
that'd
be
interesting.
Recognising
the
DRS
services
are
not
like
a
huge
section
of
the
boy.
B
That's
a
student
size
project.
You
could
you
could
give
that
to
a
student
and
say:
hey:
do
this
or
a
group
of
students
in
an
in
an
open
source
environment?
It's
not
a
bad
idea
and
we
might
want
to
interest
one
of
those
guys
one
of
those
groups
and
seeing
if
they
could
get
like
something
like
that
going
and
be
pretty
interesting
to
do
that.
So
that's
a
that's!
Actually,
a
very
good
idea,
we'll
see
if
we
can
get
that
happen.
Yes,
Bernard.
Let's.
L
B
M
N
Chris
first
then
Henning
Chris,
when
I
was
curious
and
I.
Don't
remember.
If
we
talked
on
the
list
or
in
the
last
meeting
about
authentication
giving
out
sip
credentials
is
something
we
generally
wouldn't
do
like
md5,
username
and
password.
It
would
be
more
associated
with,
and
I
and
I
saw
in
the
draft
right
now
right.
N
B
That
has
been
brought
up
in
another
environment,
I
mean
this
draft
didn't
come
out
of
thin
air,
it's
been
discussed
for
a
while
and
it
and
it
came
up
and
we're
gonna
have
to
that.
Isn't
gonna
fly
in
the
ITF
that
it's
not
secure
enough
to
do
that
yeah!
No!
It's
thank
you.
I'll
make
sure
we
get
that
in
the
notes
and
I
will
I
will
least
put
a
note
that
says
we
know
this
isn't
good
enough.
We
need
to
change
it
so
Hennings
in
the
queue
I
mean.
B
H
B
You
kind
of
broke
up
there,
but
the
question
you
had
was
about
about
confuse
or
configuration.
He
was
bringing
up
the
specific
problem
of
the
the
current
thing
has
username
and
password
in
in
files.
So
we
need
to
change
that,
but
I
I
do
hope.
Again
we
all
get
to
decide
how
much
what
the
what's
in
this
document,
the
current
document
does
have
a
mechanism
for
configuring,
the
endpoint,
that's
a
standardized
makanan
for
configuring,
the
endpoint,
that's
as
I
say
a
download
of
a
JSON
object.
It's
no
more
complicate
than
that.
B
K
B
Is
a
user?
This
is
a
uni,
not
an
N
and
I
this
this
this.
The
charter
of
this
workgroup
is
a
uni
interface.
It's
not
an
N
and
I
network
to
network
interface.
That
is
what
the
PIP
is.
That's
what
other
there
are
others.
The
IVC
document
that
are
IVC
work.
That
Henning
was
mentioning.
That
was
another
example
of
an
nni
interface.
This
is
not
one
of
those.
This
is
a
uni
interface
and
and
it's
device
and
a
user
device
to
provider,
not
provider
to
provider.
B
J
B
Is
Brian
and
and
as
as
Henning
mentioned,
the
FCC
is
contracted
with
mitre
to
do
interoperability
testing.
They
have
an
endpoint
which
meets
a
version
of
this.
This
document
that
I
did
that's
called
VAD
R
P
dat
RP
in
order
to
test
that
they
test
it
through
their
own
provider
interface,
so
that
they're
using
the
provider
to
provider
interface,
is
the
interface
point
to
test
that
endpoint
and
then
they
make
a
call
to
another
providers
endpoint
on
that,
but
so
they
you
they.
B
J
B
All
of
that
sound
of
scope
for
this
work,
I
mean
someone
could
build
such
a
system.
Actually,
writer
has
a
system
like
that,
but
it
doesn't
use.
It
doesn't
use
an
interface
like
like
the
VAT
RP
or
some
thing
it
uses
a
web
RTC,
but
it
the
that's
out
of
scope
for
this
work
right
all
that
in
scope
for
this
work
is
user
device
to
provider
we're
just.
G
K
B
K
B
When
we
were
bashing
the
Charter
for
this
group,
there
was
a
discussion
of
the
compatibility
with
WebRTC
and
earlier
drafts
of
the
Charter
had
more
definitive
statements
about
that.
It
said
that
it's
desirable
that
it
do
that.
The
current
draft,
the
current
Charter,
has
some
text,
but
it's
a
little
less
than
that.
So
just
again
speaking
as
a
participant
not
of
a
chair,
I
would
like
that
to
be
possible.
B
I
would
like
you
to
be
able
to
build
a
web
RTC
server
that
used
at
a
bug,
standard
web
RTC
in
the
browser,
client
and
built
a
sip
back-end
that
met
the
spec
and
have
it
be
able
to
work
totally
interoperability
with
any
other
VRS
endpoint
that
met
the
spec
okay.
So
that's
my
goal.
I
want
to
make
sure
I
would
appreciate.
N
J
N
The
other
comment
I
wanted
to
bring
up
was
similar
to
my
last
one
but
I
guess
related
to
the
provisioning
part
and
making
sure
the
security
like
provisioning
devices
today.
Is
there
isn't
a
lot
of
good
standards
that
the
industry
conforms
to
and
I
wonder?
If
that's
a
challenge
we
need
to
take
on
here-
and
you
know,
both
security
of
the
standard
you
know-
is
their
credentials
in
that
JSON
object
that
we
need
to
protect
from
people
snooping
or
other
things
like
that.
I.
B
Think
you're,
yeah,
I
think
you're
exactly
right.
I
think
that
if
we
can't
do
that,
then
that
ought
not
to
be
in
the
in
the
in
the
resulting
draft
and
I.
Welcome
your
your
suggestions
on
how
to
achieve
that,
but
I
mean,
as
many
people
have
noted
right,
the
ITF
has
taken
several
cracks
at
doing
provisioning,
none
of
which
have
been
implemented,
and
it
would
be
nice
if
we
built
something
that
was
implementable,
at
least
by
this
set
of
people.
B
K
O
O
We
so
far
have
not
really
discussed
contacts
and
also
the
provisioning
part.
So
the
media
and
the
SIP
are
good
and
good
improvement.
So
over
what
we
have,
we
have
an
Etsy
standard
for
VRS
and
it's
interoperability.
That
has
the
basics,
but
it
doesn't
have
the
security
and
all
the
improvements
you
have
put
into
this
spec.
So
I
think
that
would
be
good
for
global
use.
For
that
case,
but
I
don't
know
how
to
handle
the
contacts
and
provisioning.
O
O
Well,
the
GSMA.
It
has
got
its
implementation
in
USA
now
with
the
real-time
text
for
text
relay
and
text
communication,
but
I
just
noticed
that
conflict
that
is
IMS
and
web
RTC
is
not
IMS,
so
we
need
to
specify
which
way
to
go.
So
that's
my
reaction.
So
far,
I
read
this
back
and
I
think
it's
good.
Certainly
a
lot
of
points
to
discuss
so
look
thank.
B
You
well
thank
you
very
much
and
I
hope
that
you'll
participate
and
send
comments.
I
think
he
raised
two
specific
issues
that
I
didn't
want
to
address
and
then
we'll
go
on
to
the
next
person
in
the
queue
we
can.
We
certainly
can
split
up
the
document
into
multiple
documents.
If
it
makes
sense,
I'd
like
to
find
a
problem
that
we
can't
solve
relatively
quickly
before
we
immediately
jump
into
splitting
it
up,
I
would
not
do
it.
That
ultimately
happens.
I
do
hope.
B
Be
part
of
standard
with
maybe
a
statement
that
said
in
order
to
achieve
interoperability
with
an
IR,
94,
compliant
and
device.
You
would,
you
know,
use
this
subset
of
that
I.
Think
it's
a
proper
subset
I.
Don't
think
that
there's
a
there's
a
divergence
other
than
super
setting
and
sub
setting,
but
we'll
check
out.
H
Any
seam
coming
on
I-94
I
think
the
same
thing
is
I
I,
don't
think
we
need
to
emulate
everything.
I
just
want
to
make
gate
weighing,
as
you
said
about
the
about
you
Seagate
weighing
relatively
straightforward,
without
having
to
do
too
much
video
another
on
call
flow
rewriting,
even
though
it's
going
to
be
ims
on
one
side
and
more
plain
sip,
so
to
say,
on
the
other
side,
that's
relatively
easy
to
accommodate.
Bear
lots.
H
The
problem
slightly
more
tractable
is
that
we
essentially
have
a
two
stage:
visioning
model,
namely
users,
have
identities,
wave
providers
and
possibly
in
the
uod
I
thought
you
could
leverage
and
then
to
encrypt,
for
example,
credentials
which
are
then
stored
with
a
public
key
private
key
type
of
encryption
in
in
this
HTTP,
which
we
will
config
file
so
that
you
don't
have
to
install
individual
credentials
in
each
device
for
each
user.
So
there
might
be
models
for
because
of
a
particular
relationship.
H
Users
have
providers,
there
might
be
a
model
to
essentially
do
have
some
non
visible
bootstrapping,
as
in
things
that
aren't
that
are
beyond
the
scope
and
was
a
hard
but
they're
different
I
thought
you
can
use
in
that,
and
it
depends,
will
be
dominant
providers,
whether
they
are
willing
to
go
or
something
which
looks
a
little
bit
like
a
cloud
SSH
key
type
of
model
or
whoever
they
are.
They
insist
on
and
just
md5
encoded
a
strings
that
you
can
directly
copy
into
a
sip
register.
Yeah.
B
Well,
I
mean
I,
think
we'll
have
to
talk
about
this
and
maybe
we'll
maybe
I'll
start
some
email
threads
on
the
whole
thing
and
the
other
possibility
is
just
do
it.
Oh,
oh
off
I
mean
you
know,
that'll
be
good
enough.
Just
have
a
a
primary
and
have
credentials
stored.
Have
everybody
else
use
you
know,
Oh
auth
authentication
to
prove
who
you
are?
Maybe
it
not
work
I
mean
we
can
explore
something
like
that.
Chris.
N
Wanted
both
I
think
is
something
to
look
at
the
problem.
Sometimes,
as
terminals
don't
have
very
good
capabilities,
so
yeah
entering
right,
username
and
password
we're
just
playing
an
SSO
page
or
yeah,
or
if
you
want
to
do
it
indirectly,
like
you,
go
to
a
browser
link
and
enter
your
password
and
that
remotely
you
know
those
are
complex
flows
that
from
an
interoperability
point
of
you
make
may
be
difficult,
so
I.
B
I
think
we'll
probably
have
to
at
some
point
decide
just
how
far
we
want
to
go
down
whatever
rattle
we
decide,
I
think
that
used
to
be
a
bigger
problem
than
it
is
these
days.
The
devices
people
are
using
are
more
capable,
but
it's
still,
there
are
plenty
of
devices.
People
use
that
our
typing
passwords
is,
you
know
pretty
painful
any
anything
else.
K
B
The
in
the
invite
you
know
because
this
is
what
I
want
in
in
and
out
and
and
you
get
what
you
get
what
you
asked
for
I'm,
you
know.
Even
today
there
there
are
our
providers
that
have
both
an
English
cue
in
us
and
a
Spanish
cue
or
an
English
commune
of
French
cue,
so
that
that
problem
exists
they're
there,
their
solutions.
These
things
are
pretty
primitive
and
we'd
like
it
to
be
better,
but.
B
J
J
B
Yeah,
yes,
well,
let
me
put
the
new
version
out
and
coffee
adoption,
no
one,
yeah
and
and-
and
we
can
have
list
discussion-
make
sure
that
we're
okay
on
the
list
and
then
and
then
we'll
do
that.
So
that's
that's
kind
of
the
plan
will
will
will
put
out
the
new
version.
Oh
one
version,
let
it
sit
for
a
while
and
get
people,
though,
have
a
chance
to
look
at
it
and
then
we'll
call
for
adoption
on
that
on
the
list.
Son,
all
right,
great,
that's
the
plan!
Thank
you.