►
From YouTube: IETF107-RIPT-20200326-2141
Description
RIPT meeting session at IETF 107
2020/03/26 2141
https://datatracker.ietf.org/meeting/107/proceedings
A
A
A
A
A
A
So
our
agenda
today
we
have
jonathan
leading
discussion
about
the
problem
statement
and
proposed
high-level
protocol
summary
I
adjusted.
It
will
give
us
some
experiences
with
implementing
RTC
systems
at
Google
and
some
of
the
pain
points
there.
Anthony
will
discuss
the
signal,
wire,
free
switch,
use
cases
and
needs
sue.
Hoffs
is
going
to
give
us
an
overview
of
an
experimental
code
base
that
helped
to
prototype
the
the
proposals
of
protocols
and
then
finally
calling
the
lead
our
Charter
Review
and
discussion,
and
will
answer
the
both
questions
you
just
presented.
B
B
B
B
B
B
So
if
we
want
to
deploy
a
proxy
or
a
conferencing
application
or
an
IP
PBX,
you
sort
of
have
to
go
right
to
a
virtual
machine
in
these
public
cloud
environments
and
then
because
you're,
really
using
very
little
of
what
the
cloud
provider
is
offering
you
and
I
mean
by
cloud
provider.
I
mean
that
can
have
is
on
or
a
Google
or
soft,
as
your
user
to
have
to
build
a
whole
bunch
of
the
classic
layers
yourself.
So
you
have
to
do
load
balancing.
So
how
do
you
do
load
balancing?
B
Well,
you
know
sip
DNS
load,
balancing
sort
of
works
or
not.
You
know
so.
People
put
some
kind
of
proxy
forms
and
you
have
to
deploy
those,
and
then
you
have
to
make
the
public
facing.
Do
your
whole
network
configuration
separate
inside
and
outside,
and
then
you
probably
want
some
SPC's
for
security
or
where
do
you
put
those
in
front.
D
B
Side
I
get
this
sort
of
configure
all
the
IP
addressing
and
DNS
stuff.
You
have
to
configure
all
the
firewall
on
your
own
and
then
actually
a
lot
of
a
hard
part
comes
from.
How
do
you
meet
these
systems
highly
available
highly
available
voice
over
IP
software
today
is
really
hard
to
do
right,
and
we
all
know
that,
for
example,
if
you
wanted
to
employed
SPC's,
for
example,
and
a
highly
available
configuration
most
people,
do
it
by
like
virtual
IP
address,
sharing,
which,
by
the
way,
often
doesn't
work
in
these
cloud
environments
with
virtual
machines.
B
B
You
know
globally
available
worldwide
distributed
effectively
infinite
scale
near
as
our
four
I
can
tell
like
look
HTTP
load
balancer
that
does
TLS
termination
and
routes
to
your
back-end
instances
and
takes
care
of
all
the
all
the
public
IP
facing
stuff,
and
it's
easy
to
make
it
work
with
their
geo
DNS
stuff.
So
you
get
right
up
to
the
right
data
center.
B
You
literally
don't
need
to
think
about
any
like
it's
going
to
just
work,
and
then
you
have
an
additional
layer
of
tools
like
a
kubernetes
that
sits
on
top
of
it
that
you
can
deploy.
That
makes
it
really
easy
to
do
things
like
you
know,
add,
remove
capacity
and
direct
load
and
a
newer
set
of
technology
and
I'll
share
a
couple
slides
for
the
sink
old
service
mesh.
That's
really
awesome
that
does
a
lot
of
monitoring
and
troubleshooting,
and
so
there's
this
growing
stack
of
software
in
blue
here.
B
That
are
the
capabilities
that
are
provided
by
these
public
cloud
platforms
that
are
really
not
possible
to
take
advantage
of
today
by
real-time
voice
over
IP
systems,
and
so
that's
the
that's
a
problem
right
and
and
then
by
the
way,
there's
a
bunch
of
stuff
on
the
left.
That's
like
hard,
if
not
impossible,
so
elastic
peering
is
you
know,
one
of
the
ones?
B
That's
been
high,
oh
I
list,
which
is
well
if
you're
doing
something
except
chunking
or
Enterprise
enterprise
voice
over
IP,
SIP
trunking,
and
you
want
to
add
or
remove
capacity
from
your
side
elastically
on
demand.
Today.
It
afflicts
super
hard
because
there's
no
easy
way
to
do
add
capacity
without
effectively
giving
a
set
of
IP
addresses
to
your
upstream
provider,
because
the
the
DNS
solutions
for
load
balancing
for
sip
are
just
not
good
enough
anymore
for
elastic.
B
B
Do
virtual
IPS
4h
a
and
you
scale
vertically,
not
horizontally,
and
this
is
really
terrible
and
it
was
fine
back
in
the
old
days,
but
that's
not
how
it
is
org.
So
there's
this
growing
gap,
hitless
upgrades,
there's
another
thing
too
right.
The
whole
web
world
has
gone
towards
this
fully
stateless
models
as
much
as
you
can,
where
you
can
literally
just
upgrade
a
component,
and
you
know
you
middle
a
transaction.
Maybe
I'll
have
to
be
retried,
but
but
you're
not
losing
anything.
There's.
B
No,
you
know
you
didn't
lose
your
shopping
card
or
even
lose
your
purchase
or
whatever
you
were
doing
on
the
web
and
so
on
voice
over
IP,
stuff,
sipping,
RTP
stuff.
We
we
never
really
got
there.
People
use
a
variety
of
techniques.
We
invites
and
refers
to
try
and
we've
calls
around
and
they
never
were
all
standardized
and
almost
never
work
on
sort
of
cross
organizational
links.
B
So
you
have
to
wait
for
calls
to
drain,
and
sometimes
you
end
up,
dropping
really
long
calls
and
you
can't
get
the
kind
of
availability
that
you
get
from
a
modern
web
application.
So
so
that's
the
big
problem:
let's
go
to
the
next
slide
up
rotating
we're
trying
to
go
them
into
so
just
to
give
some
examples
like
this
is
a
product.
Google
just
came
out
with
called
anthro
ServiceMaster.
This
is
nice
beautiful
dashboard
of
your
uptime
and
error
rates.
Next
slide,
you
get
these
beautiful
dashboards.
Next
slide.
B
B
What
is
it
about
SIF
RTP?
That
makes
this
impossible?
Mostly
it's
not
a
web
app,
it's
not
using
HTTP,
but
there's
other
issues.
It's
not
just
that!
It's
that
we
have
IP
addresses
all
over
the
place
and
that
breaks
a
lot
of
how
these
platforms
work,
which
are
using
higher
labor
contracts
like
your
eyes
to
to
do
a
dressing,
and
then
RTP
in
the
cloud
is
particularly
problematic.
Right
and
again,
it's
heavy
use
of
IP
addresses
and
ports
for
session
identifiers.
B
B
You
can
build,
and
obviously
their
State
in
the
voice
of
our
IP
system,
especially
ones
that
have
media
in
the
cloud
which
is
largely
we're
talking
about
here,
but
you
can
use
the
web
techniques
to
do
that
so
next
slide.
But
what
I'm
going
to
do?
Actually
so
I'll
skip
this
one
sensitive
the
time
when
we
look
at
use
cases
that
we
want
to
solve
for
those
are
the
columns
here
in
this
graph
and
there's
there's
a
bunch
of
different
use
cases
that
we
would
think
about
this
new
protocol.
B
Getting
used
for
one
of
them
is
sort
of
a
browser
to
a
cloud
app.
This
is
the
area
to
some
degree
WebRTC
covers
today,
but
even
with
WebRTC,
it's
super
hard
to
make
the
RTP
piece
of
this
work,
because
us
again
of
these
challenges
in
getting
real-time
voice
and
video
in
public
cloud
infrastructure
and
I
know.
B
Today
you
get
at
them
with
G
RPC,
which
is
a
web
protocol
that
runs
over
TCP
via
these
days
and
HTTP,
of
course,
and
suffers
latency
penalties.
As
a
result,
real-time
devices
like
cameras
that
some
discussion
on
on
the
list
and
then
even
doing
things
like
SIP
trunking
so
connecting
to
the
telephone
network
between
an
enterprise
or
a
felicity,
provide
you
Cadiz
or
C
cash
provider
or
whatever
to
get
to
off
to
the
PSTN
through
a
carrier.
Using
today,
you
do
a
lot
of
SIP
trunking.
B
That
stuff
is,
is
difficult
to
do
in
public
cloud
and
so
it'd
be
great
to
have
a
better
way
to
do
that.
So
if
we
think
about
what
are
the
capabilities
that
we
need
to
do
or
to
provide
in
this
new
protocol
to
solve
that,
if
you
look
at
the
rip
draft
at
all,
it's
sort
of
broken
into
these
four
pieces,
media,
transport,
control,
media
negotiation
and
indentity
management,
and
so
that's,
what's
in
the
current
rip,
doc
that
my
cell
phone
called
and
others
put
together,
and
this
matrix
here
sort
of
helps.
B
You
understand
which
pieces
of
those
protocols
are
needed
for
of
this
protocols
need
for
these
Pharisees
cases.
So
the
best
way
to
understand
them
is
I'm,
going
to
take
the
last
few
minutes
here
and
focus
on
example,
of
how
the
protocol
works
that
we're
going
to
draft
up
so
I'll
start
with
the
rather
than
sort
of
time
order
of
how
a
call
flow
would
work
I'll
start
with
the
simplest
part
and
expand
beyond
there.
So
if
you
want
a
shuffle
media
around,
how
does
it
work
so?
B
B
That's
the
final
200.
Ok,
that
has
a
media
chunk
as
the
client
wants
to
send
media
to
the
server
it
doesn't
put
to
the
call
your
I
slash
media
with
that
media
chunk
in
the
body
and
and
that's
basically
how
it
works.
These
media
chunks
are
the
same
stuff
that
would
otherwise
appear
in
our
TV
packets,
but
we're
using
an
HTTP
encapsulation
here
to
provide
you
our
eyes
as
identifiers
as
and
other
things
that
work
better
in
the
way.
So
that's
that's
the
one
that
one
there
so,
of
course,
next
yeah
thanks
mo
next
slide.
B
So
if
we
want
to
actually
send
me,
we
probably
have
to
set
it
up
so
the
way
the
current
rip
drop
works.
Is
you
create
a
call?
The
client
creates
a
call
object
by
posting
to
the
server
to
create
a
call,
and
it
gets
back
a
call,
call
your
I,
that's
what
I
would
use
in
the
media
exchange
and
then
to
signal
so
to
do
things
like
proceeding
and
alerting
and
answered
and
decline,
and
all
the
things
that
were
all
familiar
with
here.
B
The
client
establishes
a
bi-directional
event
stream,
using
a
similar
check
at
trick
here.
This
time
is
doing
a
long,
caustic
long
pole,
with
a
gap
to
get
a
long-running
set
of
events
that
returns
streaming
JSON
and
a
put
with
streaming
JSON
on
the
request
and
those
contain
events.
Each
of
those
events
are
these
of
entries
here
on
the
right
part
of
what's
uploaded.
Here
is
a
thing
called
a
handler
that
handler
is
declaring
media
capabilities.
How
did
that
handler
show
up?
B
That's
the
next
part
of
the
flow
next
slide,
please
so
at
setup
time,
meaning
when
the
client
first
comes
online
and
it's
configured
when
it's
installed
or
when
there's
a
provisioning
change
like
a
new
account
to
set
up
these
type
of
things.
It
would
do
this
one-time
operation
where
it
tells
the
carrier
its
media
capabilities.
These
media
capabilities
are
like
what
codex
I
support
and
what
my
some
degree
of
parameterization
resolutions
frame
rates.
That
kind
of
stuff
that's
a
relatively
static
set
of
capabilities.
B
It
can
be
changed,
but
it's
not
it's
not
sent
to
the
server
during
each
call.
Super
important
understand
and
I
blew
by
this
point.
This
is
really
focused
on
use
cases
where
we
want
client
to
server
media
and
signaling
to
follow.
Each
other
is
one
of
the
key
objectives
here.
So
a
lot
of
not
all
at
many
IP
pbx
is
certainly
contact
center
software,
which
is
where
I
currently
work
conferencing.
All
of
this
variety
next
slide.
That's
what
I'm
just
about
out
of
time,
so
the
last
bit
of
it
is
a
sort
of
configuration
construct.
B
That's
in
here
largely
a
lot
of
the
details
are
in
there
specifically
for
connecting
to
the
PSTN.
They
don't
apply
to
all
use
cases,
but
but
in
this
case
there's
this
concept
called
@eg,
which
is
a
wink,
if
you
will
to
the
old-fashioned
trunk
group
construct,
but
it's
a
policy
group,
and
in
this
case
it
defined
the
server
says:
hey
you
want
to
send
and
receive
calls
great
here's
the
set
of
phone
numbers.
B
B
B
C
E
Hi
mark
on
Ian,
so
I
have
I,
guess
a
comment
and
a
concern
about
positioning
here.
It's
you
know.
Reading
the
draft
it's
talking
about.
This
is
just
the
normal
HTTP
application
and
then
the
introduction
goes
on
to
extol
the
virtues
of
being
such
a
thing
which
I
have
to
say,
warmed
my
heart.
Thank
you,
hello.
F
E
A
great
place,
I,
don't
even
wish
you
today,
it's
fantastic,
but
it
then
goes
on
to
say
that
it
seems
like
it
places
a
lot
of
dependencies
on
HTTP,
3
and
and
indeed
in
terms
of
multiplexing
and
parallelism
and
in
the
design
of
the
application.
And
my
comment
there
is
that
the
the
infrastructure
in
a
lot
of
the
cloud
providers
and
and
load
balancers
and
other
products
that
you
want
to
depend
upon.
There
is
not
necessarily
HTTP
2.
E
Yet
even
there
are
a
lot
of
folks
who
still
use
h1
in
the
back
end
or
use
H,
one
for
internal
hops
and
they're
going
to
when
they
upgrade
h2.
They'll,
probably
use
that
for
a
while.
So
I
don't
know
that
this
is
something
where
you're
going
to
really
get
those
benefits
any
time
in
the
foreseeable
future.
On
the
open,
Internet
you're,
going
to
have
to
very
carefully
choose
components
that
are
designed
for
this.
So
I'd
be
a
little
careful
in
positioning
that
way
that
it's
just
using
HTTP
yeah.
B
They're
not,
and
so
let
me
comment
on
that
absolutely
so.
The
Assumption
here
is
that
you
know
the
someone
would
you
would
someone
who's
wanting
to
avoid
a
voice
over
IP
app
using
this
technology
in
say,
Google
or
an
Amazon
or
whatever
would
be
like
waiting
for
it
to
support
HTTP
3
and
until
then
it's
going
to
have
to
we'll
be
doing
what
we've
been
doing
right
now,
we're
sort
of
into
a
race
which
is
like
well
who's
done.
B
E
G
E
B
So
here's
where
I
think
we
need
more
discussion
and
collaboration
with
the
web
trans
and
heavy
three
groups
to
sort
of
get
a
good
handle
on.
What's
the
right
approach
to
this,
that
makes
sense,
given
the
likely
timelines
of
when
things
roll
out
and
just
you
know
how
coupled
will
these
be
and
so
on
and
so
forth.
So
I
and
there's
a
bunch
of
ways.
B
E
I'll
just
leave
you
then
with
getting
that
hack
right,
so
that
it
actually
works
well
with
HTTP
one
infrastructure
and
all
those
different
places.
I
talked
about
based
upon
our
experience
with
WebSocket.
Some
of
the
things
is
going
to
be
a
really
significant
challenge
yeah.
So
this
will
not
be
easy.
Yeah.
B
H
I
H
I'm
just
concerned
I'm
a
little
bit
concerned.
Do
we
know
how
much
additional
overhead
this
is
going
to
add
because,
like
a
g.711,
you
allowed,
which
is
what
most
people
are
probably
used
to
for
audio
quality,
is
roughly
eighty
eight.
You
know
eighty
eight
point,
two
kilobits
for
my
PTSD
from
running
IP
pbx
as
before
so
I'm
wondering
how
much
additional
overhead
is
going
to
add
with
once
we
add
you
know,
HTTP,
on
top
plus
all
the
additional
HTTP
header
yeah.
B
B
So
well,
I
we
haven't
measured
it
yet
I
think
that's
something
we
should
go
and
do
but
I'll
say
a
few
things.
One
is
this
is
where
the
newer
HTTP
stuff
helps,
because
it's
binary
there's
a
lot
of
optimization.
That's
been
added
to
provide
header,
compression
and
and
as
a
result
and
the
so
I,
don't
know
how
it
will
we
probably
be
more
than
RTP.
It
will
be
less
than
if
you
try
to
do
this
on
HTTP
one
or
two
compared
to
I.
Guess
it
was.
Where
do
we
go?
B
Binary
was
a
two
or
three
I
apologize,
whichever
one
by
an
area
by
default
like
it'll,
be
you
know,
it'll
be
better
and
binary
that
it
will
in
the
text
version-
and
it's
almost
certainly
going
to
be
better
than
if
you
ran
g.711
over
RTP
is
still
probably
worse
than
opus
over
this.
So
you
know
it's
two
is
binary.
Thank
you.
I
always
apologize.
If
I
get
my,
what
features
are
on
which
version
Biggie's
confused
will
do
some
measurements,
but
in
general,
I.
B
C
B
So
at
yeah,
so
hey
I'm,
good
to
see
you
chocolate
again,
so
the
the
answer.
That
is,
that
it
sort
of
makes
this
assumption
that
the
cloud
infrastructure
for
weld
will
generally
follow
the
path
of
web
standard
work.
So
at
some
point
HT
2,
&
3
will
get
rolled
out.
You
know
I,
don't
know
how
long
it
will
take.
B
Unless
you
didn't
care
that
much
about
latency,
in
which
case
then
you
can
make
it
work
about
what
hte
do
so
you
would
sort
of
wait
for
that
and
then,
besides
that,
we
want
to
sort
of
be
as
little.
We
don't
want
to
be
different
from
the
web.
We
want
to
be
looking
as
much
and
I
don't
want
to
make
a
hundred
percent
or
zero
percent
speed.
Maybe
there
is
an
extension
to
http
a
small
tweak.
J
B
That's
one
saying
like
this
is
the
work
ahead
of
us
like
if
it
turns
out
that
web
Transport
is
coming
sooner
and
will
be
widely
supported
and
is
supported
well
in
these
cloud
platforms,
and
we
don't
need
to.
We
should
start
with
that
and
that's
cool
great
I
I,
don't
I,
know
I'm,
not
sure,
and
that's
why
the
spec
at
the
moment
actually
uses
both
okay.
Well,
it's
not
well
supported
in
public
cloud
is
just
using
UDP
alone.
B
K
Trying
to
unmute
here,
yeah
I,
just
want
to
speak
to
two
things
in
one
about
the
deployment
situation
and
two
about
overhead.
You
know
one.
You
know
as
Jonathan
points
out
the
current
deployment
situations.
You
have
to
basically
build
everything
yourself,
there's
no
cloud
server
support
except
for
VMs.
K
So
the
fact
that
h3
support
isn't
fully
there
yet
I,
don't
think
we
can
steal
it
will
show
up,
and
even
if
you
have
to
support
you
know
falling
back
to
HTTP
to
you
know
in
certain
situations
like
on
major
Internet
services,
we're
seeing
a
single-digit
number
of
single
digit
percent
of
connections
coming
in
over
HTTPS
instead
of
using
UDP
like
so
it's
impossible
to
make
this
stuff
work.
You
know
in
a
fallback
scenario
as
a
nice
to
overhead.
K
J
C
J
B
Yes,
so
there's
a
bunch
of
different
deployment
models.
One
of
them
is
that
this
would
be,
it
would
be
implemented
in
browsers.
There
would
be
a
split
I
think,
that's
exactly
how
that
would
be
split
between
the
JavaScript
app
and
the
no
line
browser
is
TBD,
but
that's
only
one
of
the
use
cases.
The
other
ones
are
like
I
call
like
I
had
this
slide
before
that
had
the
five
different
application
areas,
a
bunch
of
those
have
things
on
both
sides
that
aren't
web
browsers
or
at
all
they're.
B
Just
like
server
software,
so
I
write
a
Java
app
that
I
deploy,
and
you
know
in
some
public
cloud
environment
at
the
some
voice-over-ip
stuff
and
it
needs
to
send
a
call
to
a
carrier
and
the
carrier
is
deployed
in
spc
such
a
border
controller
and
one
of
those
s
pcs,
has
implemented
this
protocol
by
taking
an
HTTP
3
stack,
and
then
you
know
integrating
it
into
their
product.
However,
they
want
so
the
connect,
if
there's
no
browser
at
all.
B
J
So
the
kind
of
only
reason
for
being
a
web
Transport
is
to
enable
the
web
security
model,
and
in
this
case,
if
you're
not
limited
by
the
constraints
of
JavaScript,
as
in
you
could
implement
this
in
C
in
the
browser
or
you
know
outside
of
any
browser,
then
I'm
not
sure
what
you're
getting
out
of
web
transport
so
but
happy
to
take
that
offline.
Ok,.
A
K
I,
try
to
blast
through
this,
so
just
want
to
talk
a
little
bit
about
our
implementation.
Experiences
at
Google
sort
of
the
image
here
refers
to
the
fact
that
we
basically
had
to
forge
our
own
steel
when
it
comes
to
standing
up
like
a
server-based
RPC
application
for
HTTP
apps
I,
there's
like
a
ton
of
stuff,
as
Jonathan
mentioned,
you
know
in
modern
cloud
providers.
K
If
you
basically
just
want
to
like
sense
of
our
pcs
and
do
your
business
logic,
you
can
basically
go
and
point
your
business
logic
in
a
container
and
deploy
it
into
the
cloud
very
easily.
You
get
high
availability,
you
get
failover,
you
get
built-in
monitoring,
you
know
ascend,
ocation,
all
sorts
of
stuff.
You
know
when
we
built
the
first
version
of
the
reference
app
for
WebRTC
and
there's
a
little
distinction
here
off
a
clock
about
like
what
this
means.
K
K
This
is
just
me,
D,
coming
between
peers,
and
the
only
thing
that
had
to
happen
was
signaling
going
to
the
server
and
that's
something
that
HTTP
does
really
really
well
next
time,
but
for
something
like
Google
Hangouts,
you
have
the
signaling
going
for
HTTP,
but
you
actually
also
have
to
send
meet
you
to
the
server,
and
that
goes
over
SRTP,
G
or
ice.
You
know,
or
maybe
using
DTLS
if
using
data
channels
and
all
the
stuff
that
you
got
for
free
from
the
cloud.
Now
you
need
to
go
a
bit
yourself.
K
D
K
A
you
know,
scale
up
your
services,
you
know
and
be
deployed
in
lots
of
data
centers
around
the
world
and
then,
after
all,
that
you
get
to
actually
work
on
your
actual
business
logic
and
things
like
you,
know,
tooling,
and
authentication
metrics,
all
the
stuff.
You
also
have
to
build
yourself
even
in
the
browser
with
WebRTC
like
the
built-in
web
or
built-in
browser.
Dev
tools,
don't
show
you
anything.
K
We
had
to
build
our
own
web
RTC
dev
tools
so
like
this
is
a
kind
of
thing
where
you're
building
like
a
conferencing
server
like
need
to
be
prepared
to
invest
like
illiterate,
like
dozens
of
engineering
years
aside.
So
this
is
what
the
protocol
stack
ends
up.
Looking
like
you
know,
over
WebRTC
server
based
applications.
You
actually
do
your
signalling
over
HTTP
TLS
TCP,
but
then
you've
got
all
these
other
protocols
in
the
mix
for
data
and
for
infirmity
ax
and
on
the
client.
We've
got
web
RTC
in
the
browser.
K
You
know
so
WebRTC
libraries
for
mobile,
like
that
big
of
a
deal
but
on
the
server
getting
these
stacks
kind
of
deployed
and
really
tuned
out
for
a
server-side
deployment
ends
up
being
pretty
challenging.
There's
really
not
that
many
of
these
implementations
and
people
spend
a
lot
of
time
trying
to
get
the
existing
ones
to
work.
K
So
the
question
is
well:
why
do
we
need
to
actually
standardize
this?
You
know
we've
got
a
bunch
of
great
work
going
happening
in
web
transport.
That's
going
to
be
standardized
now.
What
do
we
actually
need
to
do
here?
And
you
know,
web
Transport
gives
us
a
nice.
You
know
sort
of
set
of
primitives,
but
we
also
need
to
figure
out
how
we
actually
are
going
to
expose
web
transport.
You
know
in
cloud
providers
so
that
could
actually
get
all
the
stuff
plumb
through
get
all
the
nice
sort
of
benefits.
K
We
are
hoping
for
and
also
figure
out
how
we
can
get
the
performance
we
want
when
setting
media
flows
where
the
congestion
control
needs
might
be
different
than
what
you
might
just
have
in
quit
by
default.
It
also
be
nice
if
we
could
have
some
of
interoperability
between
services.
If
I
have
a
smart,
TV
I
want
to
watch
a
live
broadcast,
that's
being
based
streamed
down
over
the
protocol.
I
just
get
a
URL
I
just
are
consuming
it
and
things
like
IP
camera
or
something
and
I
want
to
go
push
that
into
a
cloud
provider.
K
K
K
You
want
to
try
to
put
things
inside
of
quick
streams
and
then
also
to
sort
of
at
first
point
before
what
mechanisms
we
want
to
fall
back
to
when
like
h3
is
not
available,
then
beyond
that,
if
we
won't
have
interrupts
between
different
providers,
we
probably
also
need
some
HTTP
based
signaling
mechanism,
and
that
could
be
a
bunch
of
different
pieces.
First,
the
mechanisms
actually
send
our
pcs.
You
know,
and
this
and
something
like
rest
ye
RPC
si
hey
perform
this
operation,
then.
Secondly,
the
actual
logical
operations
themselves.
What
you
do
to
start
a
stream.
K
What
do
you
do
to
stop
the
stream?
Would
you
do
to
request
events
on
a
stream?
Then?
Third,
like
media
descriptions,
you
know:
are
our
favorite
punching
bag
SDP?
How
do
you
actually
describe
what
here's,
what
I
can
do,
and
you
know,
let
me
see
what
you
can
do
and
then
finally,
like
there,
you
know
other
punching
bag
offer
answer.
You
know.
What
do
we
do
to
say?
Hey
I
want
to
basically
start
watching
this
live
stream.
K
How,
if
I
intersect
the
capabilities
that
I
have
with
the
capabilities
that
the
service
providing
so
those
are
based
in
the
areas
we
can
focus
on
just
number
one.
If
we
just
want
to
get
something
done,
but
I
think
that
there's
also
a
variety
of
things
we
could
do
if
you
phone
number
two
where
you
now
like
you
know,
different
cloud
providers
or
different
clients
and
servers
center
operates
anyway.
K
C
D
C
L
D
D
You
know
even
signal
wire.
We
build
cloud
hosted
services
ourselves,
so
you
know
we
have
the
expertise
to
kind
of
bundle
some
of
these
things,
but
it's
not
very
easy
in
general,
and
it's
also
like
a
really
interesting
way
that
I
think
that
we
would
be
able
to
terminate
you
know
like
high
volumes
of
traffic,
so
being
able
to
do
that
will
kind
of
solve
a
lot
of
problems
that
the
original
sip,
but
it
was
going
to
solve.
You
know
I,
always
used
to
curse,
Wells
and
planning
our
sip.
D
You
know
because
it
looked
like
it
was
copying
HTTP
so
that
it
could
copy
the
paradigm
of
how
the
little
bouncer
used
to
work
in
the
web
2.0
days.
But
then
it
kind
of
diverged
and
never
got
to
do
it
and
I
really
think
it's
kind
of
at
least
nice
to
see
the
HTTP
evolved,
and
now
you
know
trying
to
come
back
to
leveraging
that
instead
of
having
five
million
different
set
up
protocols.
D
So
that's
one
really
important
thing
and
you
know
there's
just
like
the
way
that
we
do
things
on
the
Internet
has
changed
a
ton,
and
some
of
these
techniques
are
from
old
days
when
we
had
hardly
any
bandwidth
and
like
things
that
are
kind
of
outdated.
Now,
as
far
as
how
to
deal
with
situation
next
slide,.
D
Then
from
there
you
can
turn
things
into
sip.
Still,
if
you
have
like
legacy
world,
where
you
have
a
bunch
of
older
things,
you
know
it's
kind
of
what
we've
been
doing
forever
is
like
combining
the
future
and
past
so
they're,
still
a
bridge
between
them.
So
that'll
still
give
you
you
know
like.
You,
won't
even
have
to
really
know
too
much
about
the
rest.
You
can
still
develop
applications.
Everything
the
same
way
without
having
to
even
really
worry
about
the
profile
too
much
next.
D
D
It
is
hard
to
get
right
and
for
us
I
think
one
of
the
hardest
things
is
we
build
everything
in
C
and
I'm,
not
sure
there's
only
one
HTTP
stack
I've
seen
so
far
and
looked
at
it
yet,
but
in
order
to
pull
this
off
I
thing,
you
need
that
first,
there's
going
to
be
like
keeping
everyone
happy
with
the
wood.
You
know
the
end
users
of
calls
are
all
very
abstracted
from
this
process.
They're,
usually
just
people
answering
phones,
going
I,
don't
understand
when
things
don't
work,
so
it
generates.
D
A
lot
of
pressure
goes
uphill,
and
you
know
the
end.
Experience
has
to
be
preserved
as
well
as
little
aspects
of
telephony
passing
metadata
through
and
whatnot
that
has
to
be
considered
next,
and
so
what
I
think
that
would
happen
in
order
to
do
one
of
these
implementations,
which
I
think
that
we're
kind
of
set
to
do
one
of
the
early
kind
of
implementations
that
would
scale.
D
But
first
we
would
develop
a
stack
probably
in
its
own
open
source
library,
to
kind
of
abstract
some
of
the
concepts
and
then
once
we
did
that
anyone
else
that
was
interested
in
doing
C
type
stuff,
because
there's
a
lot
of
other
open
source
tools
and
whatnot.
They
might
be
interested
in
it.
But
we
would
then
take
that
and
use
it
to
make
a
module
into
crease,
which
itself
it's
the
project,
and
once
we
get
that
far,
then
we
would
probably
be
able
to
kind
of
test
it
in
a
while.
D
It
would
be
great
to
actually
have
some
kind
of
test
have
a
time.
I
spend
a
lot
of
time.
Building
boy
protocols
in
they
all
existed
before
I
started
so
I
had
no
say
in
it,
so
kind
of
cool
to
actually
be
able
to.
You
have
a
chance
to
figure
out
things
before
they're
ratifying
and
so
yeah
I
want.
The
other
thing
I
think
will
be
tricky,
is
figuring
out
how
to
go.
You
know
to
be
a
back-to-back
agent
or
I
think
gateway
to
other
protocols.
F
I'm,
ready,
I
think
it's
doing
doing
a
gogit
now,
okay,
so
this
so
has
I'm
I'll
try
to
kind
of
given
my
experience
of
implementing
to
go
the
dip
stack
in
the
goal
line,
it's
a
not
complete,
but
it's
working
progress
stack
the
URL
for
that
is
sides
here.
So
just
to
do
a
background.
I've
been
a
kind
of
working,
our
Cisco
being
driver
developer
product
that
kind
of
pushes
the
media
over
HTTP
to
using
gear
PC
and
have
the
servers
being
on
Cuban.
F
It
is
on
one
of
couple
of
related
cloud
Providence
and
being
able
to
kind
of
skate
all
the
benefits
that
flow'd
provides
like
what
Justin
and
Jonathan
mentioned
so
for
us
goes
on.
The
Crypt
is
basically
our
natural
evolution
of
you
know,
moving
from
HTTP
to
to
http
three,
and
hence
my
interested
in
getting
this
work.
F
Can
we
get
HD
working
through
the
cloud,
which
is
one
of
the
major
concerns
we
have
like
a
nice
to
work
today
and
magically
it
works
in?
In
addition,
the
test
appointment
that
we
had
and
also
really
see
on
terms
of
the
performance
like
the
latency
versus
the
bandwidth,
said
that
it
takes,
and
also
try
to
experiment
with
some
of
the
similar
aspects
of
the
protocol.
F
F
Yes,
JSON
encoded
format
and
send
binary,
which
is
the
audio
captured
with
/
compressed
as
media
packet
sent
over
as
with
binary
encoded
as
well
or
different
streams,
or
the
same
quick
connection
underlying
next
slide,
so
I'm
not
going
to
develop
this
flow.
This
is
exactly
the
three,
the
three
flowcharts
that
call
flows
that
Jonathan
showed
being
combined
in
one
place,
which
kind
of
shows
what
the
prototype
provides
today,
where
the
clients
like
Alice
and
Bob
and
cell
rotation,
the
ATTC,
to
instance
both
times.
F
F
Basically,
pour
that
say
slash
calls,
API,
switch
and,
and
students
get
the
calls,
and
he,
the
sender,
basically
uses
HTTP
push
to
put
the
media
packets
and
the
receiver
does
necessary,
get
to
get
the
media
packets
so
that
between
sender
and
receiver
we
can
have
a
pure
s3
based
or
media
central.
This
is
happening
next
slide.
F
One
of
the
things
that
we
already
started
trying
out
the
RipStik
was
to
see
how
complicated
is
it
to
build
something
like
crypt
today
and-
and
it
is
surprisingly,
it
was
fairly
simple
little
bit
like
is,
as
you
can
see,
that
the
total
number
amount
of
lines
of
code
that
we
would
get
a
server
and
the
client
Inc.
It
does
not
cost
2,000
lines
of
code
and
which
is
which
is
like
total.
F
It's
working
progress,
not
optimized,
and
you
know
it's
not
clearly
designed,
so
it
you
can
assume
they
can
still
optimize
it
better,
but
this
was
having
implementing
some
parts
of
the
spec
I.
I
could
definitely
say
that
building
something
like
this
was
pretty
simple
and
not
much
of
number
of
days
was
involved,
and
another
thing
is
that
the
reason
for
this
is
because
most
of
the
complexity
of
heavy
loading
is
done
by
the
underlying
quick
stack
which,
like
a
quick,
go,
provides
HTTP
3
for
us
for
free.
F
F
One
thing
that
we
saw
is
that
we
use
colors
as
a
lab
and
its
investment
to
kind
of
have
the
sender
and
receiver
running
in
Calgary
and
our
server,
which
is
running
on
ec2
running
in
Oregon
use
cluster
and
then
the
network
latency
the
network
latency
from
the
one-way
latency
from
the
sender
to
the
receiver.
We
measured
it
was
averaging
between
35
to
50
milliseconds
in
general,
and
so
the
mic
to
speaker
from
the
standard
mic
to
the
receiver.
Speaker
overall
latency
was
around
350
milliseconds.
F
Just
for
curiosity,
we
also
did
a
test
for
the
WebEx
and
monitor
see
the
measurement.
And
surprisingly,
it
was
almost
around
the
same
numbers,
probably
almost
report
a
time
as
it
was
352,
but
you
can
say
it
was
approximately-
are
all
the
same
numbers,
so
we
do
feel
with
with
a
quick
and
dirty
implementation.
We
can
still
get
the
latency
and
performance
measure
experiences
which
matches
with
existing
systems
today
and
probably
with
more
careful
thoughts
or
put
in
which
can
be
made
better
as
well.
Next
slide.
F
F
K
So
I
want
to
just
identify
that
I
bike
goes
we're
going
through
the
Charter
I
got
two
slides
at
the
end,
specifically
to
talk
about
peer-to-peer
media
and
Indian
crypto,
because
those
two
biggest
topics
that
have
been
raised
so
we
can,
we
can
hit
it
just
want.
If
you
know
say,
we've
got
that
I've
done.
There's
some
trivial
changes
have
happens
on
the
Charter
since
from
what
was
posted
to
list
I
highlight
them
in
the
Charter
here.
So
with
that,
let's
jump
right
into
it
here
and
get
the
first
slide.
K
N
K
It's
trying
to
build
this
on
top
of
h3
that
that's
the
real
thing
that
there
would
be
some
fallback
to
something
else,
but
the
primary
thing
is
a
design
goal
around
making
sure
that
we
design
something
works
on
top
of
h3.
So
I'm
going
to
pause
here
for
a
second
see,
there's
any
questions
jump
in
the
queue
about
this
slide.
K
O
K
J
It
should
say:
I
mean
I,
think
that,
like
would
ought
to
sit,
I
mean
I,
guess,
like
I
was
saying
earlier
and
I
think
Josiah
Jackson,
a
dozen
jebra
I
mean
my
thesis
and
it
from
one
sis
agree
of
me
like
as
you
do.
That
is
that
you
want
this
to
work
universally
and
they're.
Not
this
relation
is
not
that
you
can
get
UDP
through
every
firewall
in
the
world,
and
so
it's
got
to
say
something
about
how
it
works.
J
In
a
situation
where
you
don't
have
we
not
unique
penetration,
and
if
we
agree
that
page
two,
then
okay
and
if
we
agree,
if
we
want
to
say
it's,
got
to
work
in
that
case,
then
okay,
but
it's
got
to
say
something
all
right.
So
that's
not!
So
that's
really.
What
marking
for
okay,
if
you,
the
facts,
are
wrong
by
all
means
say
something
right
and
you,
like
I'm,
probably
have
any
wrong
I.
K
Think
that
the
Justin's
use
case
that
needs
to
get
through
lots
of
firewalls
for
sure
right
and
not
all
firewalls,
because
there's
no
way
a
few
gets
through
all
firewalls
and
processing
voice.
Right
so
I
mean
I
think
that
you're
always
talking
about
most
not
all,
but
a
ton
of
the
use
cases,
there's
no
firewalls
involved
at
all.
K
It's
cloud
to
cloud
use
cases
right
and
three
wide
open,
so
I
do
think,
though,
there's
large
discussion
about
a
fallback-
and
we
should
say
something
about
what
it
is
here
and
maybe
that's
something
we
should
get
a
little
more
clarification
on
of
what
what
that
fallback
exactly
looks
like,
but
I
think
that
mostly
people
have
been
talking
about,
h2
fall
backs,
but
maybe
it
should
be
something
else
than
that.
I
mean
mark
mark
nodding.
Having
comments
on
that
too
I
mean
deep
feelings
on
what
the
fallback
should
be.
What
we
should
say
there.
J
E
Do
you
know
mark
Nottingham?
Yes,
so
this
was
talked
a
lot
about
endo
and
in
other
places
and
in
BCP
this
you
know
the
problem
with
specifying
a
particular
version
of
HTTP,
whether
it's
h3
or
you
say,
pull
back
to
h2
is
that
you
don't
control
every
hakama
chain
and
even
when
you
think
you
do
need
out,
because
there
could
be
things
like
virus
checkers
and
filters
in
people's
browsers
and
when
your
stated
use
cases.
That
is
to
do
this
from
the
browser.
And
so
you
really.
E
C
L
G
P
K
A
historically
these
have
not
mixed
that
much
in
that
the
ability
that
people
want
to
do
the
broadcast
ones
are
give
them
options
a
lot
of
options
that
that
don't
that
you
don't
have
to
take
here,
though
yeah
so
I,
mean
I,
think
this
would
be
usable
for
broadcasts,
but
I
think
the
broadcast
people
buddy.
What
about
happy
believe
there
are
solutions
that
are
much
simpler,
that
don't
require
the
problems
that
happen
here,
so
they
may
not
choose
to
use
this
I.
K
So
I
think
that
that's
why
broadcast
hasn't
really
driven
any
of
these
requirements,
yet
to
say
it
they're
already
fairly
happy
with
their
like
systems,
which
have
many
of
the
properties
we're
talking
about
right.
They
work
your
load,
balancers
http-based.
Much
of
this
was
driven
by
the
type
of
stuff
HLS
and.
G
G
G
K
Okay,
so
I'd
be
perfectly
happy.
I
mean
I.
Think
you
in
a
directional
very
much,
is
very
much
in
scope
of
what
people
are
thinking
about
here
from
what
we've
heard
in
the
Charter.
So
maybe
we
should
clarify
that
that
is
both
unidirectional
and
bi-directional.
Real-Time
communications
with
that
work.
Q
Let's
see,
let's
see
if
the
microwaves
this
time,
yes
great
and
so
so
far
the
thing
that
the
real
big
question
is:
are
we
building
a
system
which
has
to
pass
the
media
over
HTTP
or
not
I
mean
if
we're?
If
we
have
to
pause
the
media
over
HTTP
and
with
real-time
operation,
then
I
have
a
hard
time
seeing
that
working
over
HTTP
one.
So
that
is
good
a
critical
point
for
we
shaded
HTTP
version.
We
aim
for.
R
Great,
my
apologies,
I
continue
to
fail
to
understand
and
I
continue
to
be
unconvinced
by
the
answers
that
were
discussed
on
the
mailing
list
that
you
can't
separate
signaling
from
call
control
in
this
new
protocol.
I
would
prefer
to
have
these
two
things
handled
separately.
I
think
the
main
argument
that
I
heard
is
paid
sharing.
This
is
not
to
me
not
a
convincing
argument.
R
K
So
I,
just
speaking
I,
think
for
many
of
the
proponents
of
this.
The
tying
those
two
together
was
that
the
signaling
follows
the
media
has
been
a
very
key
tenant.
That
many
of
us
believe
in
that's
where
we're
proposing
here
we
understand
their
systems
are
built
differently.
We
were
deeply
involved
with
those,
but
I,
don't
like
I
I.
K
You
know,
having
talked
to
a
ton
of
people
about
it,
that's
like
one
of
the
key
things
they
want
to
have
happen
here
and
the
reasons
why
are
the
reasons
that
they
put
out
about
the
load
balancers
about
leveraging
the
HTTP
environment?
All
of
those
things
so
I
mean
we
can
propose
that
or
something,
but
that
is
I
do
not
think
is
a
change.
That's
acceptable
to
a
lot
of
the
people
that
are
there
pushing
for
this
charter
and
that's
why
the
Charter
still
says
the
same
thing
it
has
for
a
year
now.
M
J
C
J
J
K
K
B
K
That
widespread
usage
is
extremely
hard
to
define
and
I'm
sure
there'd
be
a
lot
of
wiggle
room
in
the
working
group
to
try
and
do
the
right
thing
within
trying
to
figure
out
what
that
means.
But
we
couldn't
come
up
with
any
better
words
for
that.
So
that's
why
those
words
are
still
there
like
that.
Even
though
people
have
pointed
out
they're,
you
know
they're,
not
great.
K
The
the
next
parts
of
this
are
really
about
the
security
portion
of
this
much
of
the
authentication
and
various
parts
of
it
are
just
exactly
copy
the
web
model
wherever
as
possible.
There
are
some
parts
of
it
like
caller
ID,
which
mandates
the
usage
of
the
passport
things
from
stir.
Let's
try
and
have
a
strong
identity
in
it.
K
We
think
that
that's,
like
you
know,
moving
the
bar
up
substantially
from
what
we've
had
in
other
systems
and
trying
to
get
that
right
and
that
we
can
get
that
right
now
and
then
this
discussion
about
this
e
to
n
is
the
Indian
stuff
in
the
MLS
I
push
it
push
it
out
to
the
end,
because
I
ask
at
least
a
bit
more
time
on
that
one.
But
that's
that's
where
this
point
is
the
flick
three
says
in
the
Charter
and
that's
where
this
point
is.
J
Don't
worry
I'm
not
here
to
argue
about
an
end,
but
I
am
here
to
argue
about
removing
this
to
the
phrase
notably
OS
like
this
is
this
is
web,
where
it's
not
but,
like
you
know,
what's
not
signed
shrine.
The
idea
like
website
again
be
a
lot
for
a
turn.
It
over
alternative
right
I
mean
like
there's
website
occasions,
which
people
were.
However,
that
gives
itself.
O
There
are
many
other
signaling
protocols,
though,
and
one
of
the
things
which
has
affected
a
lot
of
previous
efforts
in
this
space
has
been
scope
creep,
so
we're
ever
the
thing
we
do
ones
that
replicate
all
sip.
We
may
want
to
be
a
little
bit
more
clear
about
what
features
of
the
signaling
we
do
want
to
replicate.
B
So
Colin
listen,
we
were
were
immediately
worried
about
the
same
thing
and
so
I
went
and
I
did
a
little
analysis
and
I.
Don't
pretend
I
got
it
100%
right,
but
I
think
I
got
a
problem
pretty
right
and
I
looked
at
the
core
specs
thirty
sixty
one
through
thirty
to
sixty
five,
at
least
and
and
interestingly.
B
O
B
I'm
not
I'm
not
debating
that
scope
creep
is
a
worry.
It's
just
hard
to
put
a
very
mathematical
boundary
around
it
and
that's
why
the
best
we
could
come
up
with
is
like
well
we're
not
going
to
re-implement
stuff
that
you
know
no
one
ever
implemented
or
cares
about.
That's
one
obvious
thing,
but
there's
a
lot
of
stuff.
That's
very
application.
A
B
After
that,
one
I
believe
it
it's
not
in
scope,
and
it's
a
good
example
where
you
would
mostly
be
interested
that
on
the
client
to
server
leg,
and
if
you
make
the
browser
client
sumption,
that's
the
kind
of
stuff
that
would
be
handled
with
the
application
land.
There's
no
need
for
it.
In
this
protocol.
I
B
J
M
Overall
comment
as
there's
a
lot
of
different
problems
in
this
charter,
like
there's
a
media
problem,
I
kind
of
send
the
media
over
quick
or
HTTP
three
and
there's
end-to-end
encryption
and
then
there's
a
whole
bunch
of
signaling
stuff
and
then
there's
kind
of
a
peer-to-peer
problem.
I
think
you
can
only
choose,
maybe
one
of
those
big
problems
to
solve
in
this
work
than
trying
to
do
all
of
them.
K
Think
a
lot
of
those
are
very
deeply
tied
together
and
when
we
try
and
hold
them
apart,
we
get
ourselves
in
a
lot
of
trouble
is
when
we
start
looking
at
this
stuff-
and
maybe
not
all
the
100%,
but
you
know
I
mean
I.
Think
the
essence
of
the
into
end
encryption
discussion
is
going
to
come
down
to
you.
K
K
K
I
The
previous
one
the
question
I
had
was
on
the.
If
you
go
back,
one
slide
:,
so
the
the
last
statement
I
think
it's
very
critical
given
where
we
were
with
sip,
and
you
know
now
what
we
have
done
with
stir
to
mitigate
some
of
the
issues
that
actually
we
had
with
sip,
so
I
think
it
might
be
worth
not
to
design
something
here,
but
something
that
is
more
explicit
than
what
we
are
saying
here,
that
this
extension
will
also
utilize
stir
or
caller
ID.
G
J
K
J
I'm
sorry
I,
just
not
I,
think
I
think
that's
really
seems
like
a
good.
That's
only
seems
like
a
good
theory,
but
I
think
it's
primal
more
place
than
that
because,
on
you
know
be
I
mean
so
one
theory
would
be
that
it
has
to
be
implementable,
an
unmodified
web
browser.
It
doesn't
have
anything
other
than
web
transport
right
and
that
would
require,
and
that
would
place
the
requirements
print
of
what
HTTP
on
mechanics
you
can.
You
can't
can
can't
use
on
and
so
I
think
like.
K
K
J
I
guess
I
guess
I'm
trying
to
figure
out
distinguish
between
like
we'd
be
nice.
If
that
happened
or
would
it
be
like?
Is
it
a
requirement
for
the
design
so
I
mean,
like
you
know,
like
cuz
there's
one
might
imagine
putting
things
in
I
mean
accidentally
or
intentionally
that
they
made
that
impossible.
You
know
you
need
a
new,
a
new,
a
new
beaver
for
something
right
and
so
like
if
we're
trying
to
design
with
that
in
mind
and
I
agree
with
you
that
it
should
be
possible.
J
K
Sure,
well,
I,
didn't
we
say
should
be
implementable.
You
know
we
should
say
you
know
by
JavaScript
applications
using
nothing
more
than
web
transport
and
web
codecs,
or
you
know,
even
to
say,
without
saying
nothing
more
than
we've
even
just
save
of
transport.
Web
codecs
is
the
primitive
suite
dump
table.
E
Yeah
so
ekor
ask
the
first
part
of
my
question.
The
follow-up
is,
if
it's
available
from
browsers
without
any
modification,
how
does
this
affect
the
threat
model?
You
know.
Are
we
going
to
have
advertisements?
You
know
in
with
malware
in
them,
making
four
hundred
thousand
phone
calls
to
my
number
now,
because
it's
available
every.
K
E
K
Well,
I
feel
very
differently.
I,
don't
think
Justin
for
a
second
was
was
proposing
that
you
know
this
I'd
be
open
to
some
job,
terrifical
tax
access,
your
your
mics
and
whatever
your
mics
in
the
cameras
and
speakers
with
it.
You
know
without
some
sort
of
permission
model
and
all
that
stuff
right.
It
was
you
know
it's
the
whole
web
codecs
discussion,
so
right.
E
Why,
actually,
what
do
you
think
of
that
I?
Don't
think
on
the
server
side
you
know:
are
the
server
is
going
to
have
the
discipline
you
know
they're
not
may
be
used
to
this
threat
model
where
any
random
web
browser
can
open
a
connection
and
request
a
phone
call.
Is
that
going
to
be
different
for
that?
Oh
I.
K
Like
everybody
that
builds
a
server
that
allows
you
to
make
a
phone
call
on
some
communications
to
is
certainly
going
to
want
to
authorize
and
figure
out
how
to
do
that.
I
mean
that's,
but
I,
don't
I'm
not
seeing
that
really
changes,
I
mean
how
people
now
connected
through
a
web
browser
and
it
authorized
living
decided
whether
they
let
them
in
or
not.
I
mean
now
see.
C
K
B
So
I
just
wanted
to
say
this
is
sort
of
mark.
One
of
the
reasons
why
the
client-to-server
media
also
makes
things
a
lot
easier.
A
lot
of
the
challenge
with
WebRTC
was
like.
Oh
I
can
tell
the
browser
to
send
media
anywhere
to
any
IP
I,
just
I
so
desire,
which
is
like
a
ginormous
das
hammer
because
ripped
in
its
current
design
focuses
on
you
know
it's
just
a
it
use.
B
It
tries
to
you,
reuse
the
web
security
model
right,
you
connect
to
the
server
and
that's
where
you
send
stuff,
there's,
no
there's
no
ability
to
target.
You
know
random
places
or
what
have
you
that
are
different
from
where
the
we're
the
browser's
going
to
it
that
doesn't
address
the
access
to
Cameron
Mike
problem,
but
it
that
would
be
what
remains
is
just
access
to
Cameron
right.
K
I
think
you
know
I
mean
because
somebody
pointed
out
this
this
this
is
heavily
dependent
on
a
working
group
that
was
just
hard
depending
on
a
draft
that
you
know
is
still
in
I
mean
obviously
we're
like
this
whole
idea.
Even
on
quick,
it's
not
just
quick
we're
we're
relying
on
the
Datagram
stuff
and
quick
working
for
any
of
this
to
make
any
sense
at
all.
So
it's
a
bunch
of
different
working
groups
to
coordinating
with
here
a
whole
lot
of
work.
K
S
S
Included
so
I
asked
this
question
in
the
integer.
What
is
the
extra
dependency
on
web
transport
because
there
to
me
the
worst
dependency
quick
is
kind
of
more
or
less
hopefully
done,
but
web
transport
just
starts.
If
there
is
there
an
option
to
like
not
have
web
transport
and
edit
later
or
is
this
a
stronger
penalty,
I.
K
Think
that,
as
this
call
went
on
today
and
David's
comments
earlier,
I
think
that
this
is
really
only
a
dependency
about
how
this
reflects
up
into
the
browser.
It
might
not
be
a
dependency
at
all.
So
let's
say
that
we
were
saying
to
implement
ripped
in
a
browser.
You
need
to
write
a
bunch
of
browser
codes,
could
do
it
as
a
JavaScript,
then
I,
don't
think
we
have
really
any
dependency
on
web
transport.
K
But
if
we're
saying
you
can
do
it
mostly
in
JavaScript,
with
a
few
extensions,
a
few
additions
to
the
browser
or
to
a
browser
that
had
web
codecs
and
web
transport,
then
obviously
that
part
would
be
completely
dependent
on
web
transport.
So
I
think
that
this
dependency
is
a
little
bit
vague
right
now,
depending
on
where
we
want
to
be
there.
But
the
dependency
on
on
quick
and
quick,
Datagram
and
particular
stuff
is
I
mean
we're
we're
very
dependent
on
it.
So.
S
K
Q
K
Q
C
N
C
C
Okay,
so
I'm
just
confirming
that
the
people
remaining
on
the
list
are
trying
to
make
general
comments,
because
we
have
a
bunch
of
other
slides
that
we
want
to
work
through
before
we
get
to
the
general
discussion,
so
I'm
going
to
ask,
come
under
move
on
and
then
all
those
people
who've
queued
I'll,
keep
you
in
mind
for
the
general
discussion
when
we
get
to
the
end
all
right.
It's
just
two
more
coming
up.
K
It's
a
real
identity
are
pretty
much
sighs.
Okay,
deliverables,
I.
Don't
think
that
these
are
worth
much
discussion
we
can.
We
can
go
over
them,
but
you
know.
Basically,
we
see
this
as
layering
into
some
stuff
for
sending
the
media
and
I
suspect
that
when
I
wrote,
this
I
got
the
h2
wrong.
Here.
That's
my
fall.
I
think
where
this
probably
should
say:
h3
and
HTTP.
K
It's
just
the
rest
calls
there's.
We
need
some
way
of
describing
what
the
media
it
type
of
the
media
is
that
you're
sending
we
need
stuff
some
stuff.
That's
are
really
around
the
identity
management
of
what
what's
the
identity,
what
the
identities
can
you
use
and
then
which
ones
you're
using
when
you're
calling
stop
point
when
we
break.
K
K
K
A
K
J
J
J
K
K
K
For
example,
a
data
center
that
I
mean
like
half
the
use
cases
are
basically
like
a
data
centers
trying
to
send
something
to
another
ASRs
two
minutes.
It's
not
a
multiparty
call.
It's
simple
one
now,
obviously
I
think
there's
use
cases
to
like
a
you
know,
hangouts
conference
or
something
where
there's
lots
of
users
that
are
all
trying
to
share
it
in
media.
It
makes
sense,
but
you
know
the
SIP
trunking
use
cases,
the
the
other
ones
are
not
in
that
category.
Obviously,
right.
J
K
K
So
look
I,
don't
have
wrong
with
that
at
all,
I
mean
I
want
that
ending
as
well.
I
agree
with
you,
so
I
don't
have
a
problem
with
that,
but
where
we
fall
down
the
slippery
slope
up
on
that
because
Indian
encryptions
one
thing
Indian
key
mechanism
is
another
and
an
end
and
working
identity
scheme
is
another
right
and
you
need
all
three
before
you
have
a
workable
system,
so
I
I
think.
J
L
K
N
Yes,
so
I
was
saying,
I
mean
I
was
just
going
to
covered
I.
Think
they
allow
for
in
this
wording
is
awfully
vague
in
the
sense
that
it's
like
you
know
it
could
be
interpreted
as
meaning
yeah.
If
you
wanted
to
end
and
media
encryption
yourself,
knock
yourself
out
we're
not
going
to
help
you
I,
don't
think
it's
what
you
mean,
but
the
wording
here
seems
to
allow
that
I
think.
B
Yeah
I
just
want
to
make
sure
we're
clear
that
how
end-to-end
encryption
is
not
the
same
as
p2p
media
right.
We
can
still
have
client-server
media
and
haven't
an
encryption
now
and
then,
besides,
that,
I
want
to
really
echo
a
lot
of
other
people.
Saying
there's
a
lot
of
the
use
case
that
people
want
to
solve
for
are
like.
We
want
to
make
a
call
to
the
PSTN
and
those
are
just.
B
There
is
no
end
encryption
there
and
I
want
to
make
sure
we
don't
end
up
with
a
protocol
that
is
only
usable
in
environments
where
it's
like
a
browser
to
browser
inside
of
the
same
service,
because
you
know
that's
what
10.
So
that's.
Why,
for
me,
it's
and
also
I,
really
don't
want
to
invent
another
team
protocol.
So
you
know
to
me
that
the
goal
is
that
the
protocol
supports
an
encryption,
but
it
uses
other
protocols
to
provide
the
keying
out
of
the
band,
meaning
not
in
the
scope
of
this
protocol.
B
So
if
you
had
a
group
of
people
who
are
communicating
on
a
you
know
from
their
browsers,
Ector
like
you
were
saying,
they
would
do
something
else.
Get
the
keys
and
then
once
they've
got
those
keys
and
agreed
upon
those
keys
outstanding.
Now
they
want
to
place
their
voice
call
now
they
use
ripped
and
ripped
as
a
way
for
them
to
indicate
hey
I'm
using
this
key
I
learned
elsewhere
did
not
do
the
keying
in
this
protocol.
That's
what
I
really
do
not
want
to
do.
J
B
J
K
C
T
So
there
are
many
layers
to
this
protocol.
There
is
the
media
transport
and
about
this
earth
like
negotiation
and
above
that
there
is
a
whole
sip
replacement.
Enchilada
and
I
would
like
to
emphasize
that
a
lot
of
uses
or
transferring
media
over
HTTP
in
the
cloud
or
completely
not
related
to
telephony,
and
you.
L
L
T
I
have
a
live
stream
and
I'm
trying
to
send
it
to
a
cloud
like
transcription
service
and
in
those
cases
enter
into
encryption,
doesn't
make
any
sense
at
all
and
I
want
to
make
sure
that
we
understand
that
there
also
serve
cases,
but
so
for
at
least
the
media
transport
layer.
I
want
to
make
sure
that
it
works
for
cases
where
the
server
is
the
endpoint
and
the
client
is
at
our
endpoint.
K
G
Was
opportune
what
advisee
justin
is
when
you
have
multiple
these
hops
chained
together
it
protects
the
medium
the
intermediate
servers
I
was
originally
in
cute,
so
it's
a
kind
of
post,
one
Egger
and
to
having
so
arm
here.
The
beach
vp
on
by
default
suggestions,
point
about
being
primarily
hop-by-hop.
I
think
the
way
that
materialized
would
be
to
have
like
the
slots
where
you
would
overlay
something.
G
I
I
G
It
is
an
implication
of
having
it
by
defaults
to
sorry
Jonathan,
but
an
implication
of
that
is
that
we
will
need
to
point
to
some.
We
wanted
to
include
a
pointer
to
some
key
negotiation
protocol,
but
I've
been
chatting
background,
thecar
and
I.
Think
I'm
convinced
at
this
point
there's
enough
options
here
that
something
we
should
be
able
to
just
point
to
something
that
that
will
make
make
be
able
to
work.
G
M
K
The
initial
idea
of
a
bunch
of
the
proponents
in
this
working
group
was:
let's
not
do
that
that
we
had
like
that
was
a
lot
of
complexity.
Let's
just
start
with
something
simple
and
in
fact
that
this,
whatever
the
protocol,
the
ripped
protocol
is
probably
run
a
bowl
over
a
data
chat,
WebRTC
detail
that
could
set
up
for
the
peer-to-peer
thing
so
that
that
that
is
certainly
the
current
thinking
is
the
simplifications
of
that
drives
it
to?
K
Let's
just
make
this
purely
client-server
that
solves
us
with
a
lot
of
use
cases
and
where
the
use
cases
where
that
doesn't
work
fall
back
to
WebRTC.
So
that
is
that
the
current
way,
the
Charter
I
think
is
phrased.
But
is
you
know
this
has
been
raised
as
an
open
issue
of
that?
Well,
it
would
be
nice
to
have
peer-to-peer
media
as
well.
So
let
me
just
leave
it
there
and
let
people
want
to
comment
on
this.
Talk
about
it.
Q
Understand
and
for
once,
a
I
hardly
agree
with
Kevin
and
have
a
couple
of
points
to
add
to
the
pile
up
to
the
bonfire
of
of
not
doing
it
to
be
well.
Is
that
a
lot
of
the
security
models
that
make
HTTP
such
attractive
and
attack
them
users
and
depend
on
the
idea
of
server
identity?
Peter
P
doesn't
have
server
identity.
How
do
you
have
identity
and
so
I
think
leaving
this
out
of
scope
makes
the
makes
a
think
much
clearer.
We
should
even
say
explicitly
that
we're
only
deploying
this
in
it.
The
client-server
model.
J
Ericka
Scola
yeah,
if
you're
going
to
be
the
hater
again
here,
but
no
I,
don't
think
I'm
not
on
board
with
this
either
on
so
odd,
in
fact
that
I'm,
you
know
at
the
same
time
as
we're
having
people
are
having
substantial
trouble
with
centralized
conferencing
systems
following
over.
Do
the
excessive
load
that
we're
proposing
having
everything
be
centralized.
J
O
Q
Yeah
they
I
remember
the
other
part
of
that's.
The
point
was
the
motivation
slides
for
this
all
talk
about
deployments
in
the
data
center.
Every
single
one
of
these
arguments
is
null
and
void
for
p2p
I'm,
very
in
favor
of
reusable
components
that
can
be
used
both
on
p2p
and
in
this
protocol.
But
this
particular
proposal
is
client-server
and
children
should
admit
to
it
and
be
allowed
to
do
it.
K
C
K
Are
out
in
the
field
with
client-to-server,
you
can
upgrade
the
client
and
server
a
lot
of
times,
both
yourself
and
you
can
move
a
little
bit
faster.
So
I
think
we
probably
start
with
client
to
server
rely
on
WebRTC
for
client
to
client,
some
time
being
and
eventually
support
rift
over,
say
ice
as
a
mechanism
to
bring
the
same
protocol
to
peer-to-peer.
M
C
M
So,
just
that
just
a
point
as
Harold
said,
we're
really
been
talking
a
lot
about
HTTP
here
and
in
the
web
transport
kind
of
terminology.
That's
what
we
call
a
HTTP
transport
and
so
you'd
look
at
datagrams.
They
would
be
HTTP
three
datagrams,
whereas,
if
you're
looking
at
peer-to-peer,
you
probably
don't
want
to
do
HTTP
three
on
a
peer-to-peer
manner,
so
you're
talking
about
what
we
call
quick
transport,
which
is
just
the
raw,
quick
and
then
you're
talking
about
quick
Datagram.
M
So
these
are
kind
of
very
different
things,
and
this
presentation
is
I
think
mostly
been
about
kind
of
clients
or
HTTP.
Three,
in
which
case
sets
that's
really
not
a
peer-to-peer
environment,
but
some
of
the
media
stuff.
If
you
define
RTP
over
datagrams
right,
it
works
for
HDC
datagrams
or
for
the
quick
difference.
C
Ok,
I
think
we're
going
to
try
to
field
some
questions
now
about
the
Charter
more
broadly,
but
we
don't
have
a
whole
lot
of
time.
So,
if
there's
anything,
people
have
I
did
have
a
list
of
people
further
up
in
the
chat
there
leave
that
included
not
Nottingham
and
expensive,
Elkins
and
Watson's.
Please
be
brief.
We
would
like
to
ask
a
couple
of
questions
before
we
leave.
So
let's
go
where
and
not.
E
Think
it's
going
to
bill
in
really
interesting
ways
and
certain
deployments
and
so
I
think
the
Charter
needs
some
wiggle
room
in
the
deliverables
so
that
we
can
have
a
discussion
about
what
the
desired
fall.
Buck
scenarios
are
and
whether
it's
better
to
fall
hock
fail
hard.
If
you
can't
establish
you
know,
for
example,
a
quick
web
transport
connection
rather.
D
M
So
and
jabbered
has
been
some
discussion
about
a
gap
between
the
semantics
of
HTTP
which
make
those
things
like
the
stateless
load,
balancers,
etc
in
the
auto
scaling
work
and
the
demands
of
connecting
to
clients
to
the
same
server.
So
you
can
have
a
telephone
conversation
between
them.
It
seems
to
me,
like
some
of
the
inherent
properties
of
each
system
are
in
conflict.
A
You
might
want
to
make
a
list
of
the
things
that
you
are
depending
on
that
aren't
quite
there
yet
like
web
transport
and
quick
data
grams,
and
things
like
that.
If
this
is
supposed
to
be
a
short-term
kind
of
deliverable,
because
I
had
some
concerns
about
that-
and
the
other
thing,
that's
probably
worth
me
saying,
is
I'm
really
hoping
that
you
all
find
out
things
about
media
over
quick
whatever?
That
means
that
we
can
use
in
lots
of
other
places.
A
So
I
would
hope
that
you
know
I
mean
like
I
was
thinking
to
the
point
of.
Does
that?
Does
that
even
need
to
be
in
the
same
working
group
as
the
rest
of
this
stuff?
Maybe
it
does,
but
I
would
hope
you'd
be
thinking
about
the
general
case
of
media
over
quick
so
that
we're
not
doing
another
one
in
a
year
or
two,
because
the
this
one
wouldn't
work
out.
Thank
you.
B
B
P
Sorry,
if
your
minagawa
assume
so
my
concern
here
is
about,
we
actually
I
think
we
need
to
cut
these
things
up
a
bit
and-
and
I
think
the
media
transport
part
is
something
which
you
can
actually
separate
from
the
signal
stuff
and
still
have
maybe
some
of
these
stage
sharing,
etc
working.
But
it's
need
to
be
looked
at
because
I
think
it's
needed
over
quick
or
h3.
It's
going
to
be
something
is
going
to
be
reused
in
a
lot
of
different
settings
and
it
can't
be
tightly
coupled.
P
The
other
aspect
of
this
I
think
is
to
not
repeat
the
octopus
mistake
and
not
be
clear
on
the
media
model
and
how
you
handle
mod,
even
if
it's
not
in
scope
immediately
the
multi-party
questions
they're
going
to
come
in
here,
they
des
again
come
in
at
some
point
and
you're
going
to
handle
them
and
you
need
a
model
for
it.
Otherwise,
you're
going
to
miss
things
which
report
from
the
pointers
starting
point.
Thank
you.
C
A
N
C
What's
worked
in
other
sessions
here
is
people
who
are
willing
to
contribute
effort
into
pursuing
work
in
this
general
space
and
realize
that
that
work
will
initially
be
defining
the
scope
more
clearly,
please
put
a
plus
one
into
the
WebEx
chat
and
we'll
tally
that
up
and
then,
while
you're
doing
that,
anyone
who
is
willing
it
who
thinks
this
is
a
bad
idea
generally
and
has
specific
reasons
why
we
shouldn't
be
pursuing
something
in
this
area.
Please
join
the
mic.
Q
I'll
try
to
filter
those
out.
C
E
H
I,
you
know
is
more
a
comment.
You
know,
I
think
a
trying
to
keep
this
scope
for
this
I
think
just
go
for
it
narrow
enough
that
it's
attainable
with
the
people
who
are
engaged
I.
Think
is
really
going
to
be
here
because,
given
the
areas
where
we
can
potentially
go
with,
this
I
suspect
that
there's
someone
there's
a
lot
of
places
where
we
can
accidentally
end
up
in
the
ditch.
Even
if
everybody
is
well-intentioned.