►
From YouTube: IETF96-SIPCORE-20160720-1550
Description
SIPCORE meeting session at IETF96
2016/07/20 1550
A
Put
yourself
in
the
queue
or
something
like
that
in
any
case,
we'll
go
ahead
and
get
the
chair
administrivia
out
of
the
way
you
should
definitely
buy
now
note.
The
note
well
is
I
recognize
most
of
the
faces
in
this
room
and
know
that
you
know
what
this
means
for
the
few.
I
don't
know
I'm
going
to
point
out
that
if
you
have
not
read
bcp
78
and
79
and
you'll
want
to
say
something,
the
microphone
go,
read
78
and
79.
First,
because
it
might
have
implications
on
your
IPR.
A
A
A
C
C
C
Not
a
huge
turnout,
okay,
the
problems
that
have
to
be
solved
is
that
the
course
if
rfcs
are
written
to
support
both
ipv4
and
ipv6,
but
unfortunately
they
don't
handle
dual
stack
deployments
very
well.
Rfc
6157
talks
about
ipv6
transition,
but
it
doesn't
solve
the
happy
eyeballs
problem
fact:
it
simply
states
that
it's
a
problem
and
as
discussed
extensively
on
the
list
in
the
past
3263,
is
not
clear
on
the
DNS
procedures
to
be
used
in
dual
stack
networks
and
also.
C
It
addresses
the
narrow
problems
of
DNS,
SRV,
record
lookups
of
sip
servers
and
dual
stack
environments.
It
basically
cleans
up
these
procedures
to
be
what
everyone
thinks
they
ought
to
be,
but
was
not
actually
written
as
such.
It
addresses
these
two
issues
by
requiring
that
both
a
and
quadruple
a
records
be
looked
up
by
dual
stack
devices
and
then
documents
that,
as
a
consequence
of
all
of
this
DNS
SRV
records
can
be
used
by
a
server.
It
indicates
preference
of
address
family
to
communicate
with
it.
C
This
one
is
titled
the
next
increment
of
work,
which
is
basically
what's
needed
to
solve
the
fundamental,
the
fundamental
happy
eyeballs
problem
with
sip.
We
need
to
allow
devices
to
change
the
target
order,
that's
prescribed
by
rfcs,
3263
and
2782,
so
that
it
can
give,
for
instance,
to
two
targets
that
are
known
to
work
correctly.
We
need
to
encourage
UAE's
to
either
maintain
flows
or
to
probe
targets
before
sending
requests
to
them
so
that
it
doesn't
get
stuck
having
to
wait
for
requests
to
time
out.
C
We
need
to
reduce
transaction
timeouts
which
right
now
default
to
32
seconds,
because
if
an
invite
request
waits
32
seconds
to
timeout,
the
user
is
going
to
hang
up
before
the
UA
can
fall
back
to
the
second
target,
and
we
need
to
make
sure
that
current
UDP
approaches
are
still
supported,
because
that's
what
people
use
in
large-scale
dual
stack
deployments
now.
A
very
preliminary
version
of
this
work
is
in
a
draft
that
I've
composed
draft
whirly
sip
core
dual
stack.
C
Okay,
in
regard
to
changing
the
target
order,
which
is
the
title
of
this
slide
strictly
changing
the
target
order
is
allowed
by
RFC
3261
in
section
8.1
point2
as
local
policy,
but
up
until
now,
no
seems
that
no
one
has
ever
actually
talked
about
doing
it.
What
we
do
need
to
do
is
to
give
implementers
detailed
guidance
on
how
to
reorder
targets
to
get
better
back
to
better
get
better
effects.
C
Otherwise,
we
wind
up
with
duplicate
requests,
causing
merge,
requests
at
the
destination,
and
we
need
to
have
a
consistency
requirement
that
if
the
a
set
of
targets
are
accessible
for
a
long
time,
the
behavior
of
the
UA
in
regard
to
the
distribution
of
traffic
among
them
must
approximate
over
the
long
time
what
3263
prescribes
in
particular,
cached
information
about
non
reach.
Ability
has
to
timeout
next
slide.
Please.
C
The
UAE's
should
maintain
some
sort
of
current
flow
status
with
the
targets
of
its
home
proxies,
so
it
knows
which
targets
are
accessible
in
which
or
not
there's
many
different
ways
of
doing
this.
Sip
outbound,
RC
5626,
is
the
best
known
of
these
alternative
is
that
the
UA
could
probe
the
targets
before
sending
sending
requests
to
them.
They
can
do
this
by
various
keep-alive
methods.
C
C
Ok,
this
is
titled
reduced
transaction
timeouts,
currently,
timer
be
and
timer
F,
which
are
the
invite
and
non
invite.
Transaction
timeouts
are
set
to
64
times,
t1
t1
being
the
the
estimated
round-trip
time
on
the
default.
T1
is
500
milliseconds,
which
makes
the
default
timer
be
and
timer
f
32
seconds.
This
is
actually
much
too
long
to
be
used
for
fall
back
in
invite
requests
in
practice.
C
Unfortunately,
reducing
t1
is
probably
not
a
good
idea
because
it
affects
many
other
times
throughout
sip
as
well.
If
we
reduce
timers
BNF
without
reducing
t1,
that
lowers
the
number
of
retransmissions
unless
we
change
the
retransmission
schedule
and
in
any
case
shorter
time,
outs
are
more
vulnerable
to
intermittent
connectivity.
C
C
Okay,
this
is
the
first
slide
on
large-scale
dual
stack
deployment.
The
next
block
of
work
is
a
series
of
issues
that
show
up
in
large-scale
deployments
and
become
intensified
with
dual
stack
deployments
because
of
overhead
concerns.
Dual
stack
usage
has
to
support
something
resembling
current
UDP
approaches.
C
Sip
outbound
is
understood
as
the
correct
way
of
doing
many
of
solving
many
of
these
problems,
but
it's
not
widely
deployed.
We
need
to
make
sure
we
have
a
good
understanding
of
hawai
which,
as
I
said,
seems
to
be
a
perception
that
the
overhead
involved
is
excessive.
We
need
to
know
why
that
is,
and
it's
worth
checking
should
we
define
some
sort
of
subset
or
revision
of
outbound
that
reduces
these
overheads
so
that
overhead
by
our
outbound
can
be
used
effectively
in
in
very
large
deployments.
C
C
What
we
really
want
to
do
is
to
have
sip
handle
all
these
things
in
herre
inherently
and
then
stop
the
AL
G's
from
messing
everything
up
d
TLS
is
similarly
seen
as
having
excessive
state
and
overhead
requirements,
but
it
seems
possible
that
we
can
come
up
with
some
sort
of
subset
or
variant
of
DTLS.
The
piggybacks
on
the
work
we've
already
done,
but
avoid
dtls
is
difficulties
next
slide.
Please.
C
Our
big
problem
is:
there
is
instability
in
networks,
particularly
with
mobile
usage.
You
get
changing
connectivity
as
to
which
IP
addresses
the
device
is
using,
and
even
what
I
address-family
it's
using
you
get
intermittent
network
connectivity
among
one
of
the
things
that's
necessary
to
make.
This
work
is
some
sort
of
good
good
failure.
Detection
you
can
detect
failures
through
through
the
failure
of
signaling,
keep
our
lives
on.
You
can
detect
it
to
the
absence
of
media
or
really
what's
better,
the
absence
of
our
TCP,
since
even
when
you're
on
hole,
you
still
get
rtcp.
C
You
also
get
status
reports
up
from
the
networking
layer.
The
things
that
need
to
be
done
is
some
massive
call
recovery,
so
the
call
doesn't
get
lost
and
also
we
need,
unfortunately,
to
have
do
transaction
recovery,
which
is
more
difficult
problem,
not
so
much
for
in
dialogue
transactions,
but
for
invites,
which
can
last
for
a
long
time
and
are
much
more
vulnerable
to
on
instability.
And
we
have
to
make
sure
that
that
we
handle
the
interaction
with
sufficient
timers
correctly.
C
A
A
C
A
D
Allah
Johansson
I
think
this
is
out
of
scope
for
the
work
on
hype,
eyeballs
and
I.
Think
if
you
switch
the
previous
slide,
I
think
this
also
is
not
really
in
scope
and
I
would
like
to
focus
on
setting
up
a
flow
and
that's
the
whole
focus.
Now
that
we
have
the
other
drafting
process,
we
need
to
discuss
how
to
set
up
the
flow
and
the
way
I
personally
see
it,
and
I
thinkin
saulo
is
with
me.
E
D
As
we
discussed
incipit
an
event,
I'm
sure
you
know,
outbound
doesn't
cover
any
recovery
of
a
call,
and
that's
not
something.
I
would
like
to
work
on
at
some
point
up
on
focus
on
setting
up
to
call,
but
we
still
need
recovery
or
in
retargeting
I
think
that's
good
work,
but
not
related
to
help
eyeballs
and
it
can
come
on
IP
to
I,
peed
I.
Think
Roman
on
the
mailing
list
told
us
that,
even
when
you
switch
from
4G
2
3g,
you
get
a
new
IP
address
allocated
in
some
networks.
G
F
Okay,
create
a
homer
I'd
like
to
know
what
the
definition
I
think
I've
asked
this
before,
and
it's
not
clear
to
me
at
what
the
definition
of
flow
is.
When
someone
talks
about
sending
options
with
max
forward
zero,
it
seems
to
me
okay,
this
is
a
flow
flow
that
goes
to
the
next
hop
because
you're
testing
the
flow
and
that
next
stop
is
going
to
reject
it.
The
output
definition
of
a
flow
is
something
that
goes
from
the
ue
to
the
register,
but
then
again
at
some
point,
I
think
someone
talked
about
the
no
no.
F
The
flow
goes
to
the
register.
We,
you
have
the
edge
out
pond
proxies,
but
the
flow
and
terminates
at
the
register.
But
then
again,
I
heard
see
this
word
target
so
that
to
me
saying,
okay,
this
flow
is
something
that
goes
into
end.
So
I'd
really
like
to
know
what
what
is
the
definition
of
flow
in
this
case.
F
G
The
way
again,
I
see
this
problem
is
what
you
have
is
you
have
a
client
which
has
more
than
one
network
available
in
leptin
is
not
only
limited.
The
door
stack
it's
limited
to,
for
instance,
having
multiple
local
eighties,
and
you
do
some
sort
of
DNS
resolution
and
you
have
multiple
remote
targets
available.
G
Her
wish
you
can
connect
to
the
registrar,
so
you
have
almost
like
an
ice-like
set
of
original
origination
address
the
center
and
destination
addresses
and
realistically
client
needs
to
figure
out
which
source
and
destination
IP
is
to
use
to
say
to
send
a
message,
and
that's
fundamentally
the
problem
that
we're
trying
to
solve.
So
in
this
regard.
G
I
think
this
is
essentially
a
flow
that
clients
that
needs
to
pick,
and
we
need
to
have
a
mechanism
on
how
to
pick
which
flow
to
use
for
the
next
sip
message
and,
depending
in
the
scope,
it's
either
the
flow
for
the
entire
transaction
or
even
a
flow
for
each
next
sip
message
in
the
transaction.
Again.
If
the
transaction
is
long
running
for
the
long
time
such
as
like,
for
instance,
initial
invites.
A
H
F
F
H
D
Well,
Lee
Jones
on
here
I,
don't
see
any
difference
in
those
two
cases.
Yet
when
I
looked
at
this
I
mean
it's
just
about
finding
a
possible
IP
address
to
play
with
given
a
one
dns
name
right,
and
that
applies
to
both
cases,
but
in
response
to
Krista
I'll
pan
doesn't
require
you
to
set
up
all
those
flows.
It
requires
an
implementation
to
support
at
least
two
flows,
but
you
can
run
it
with
one
flow
and
that
really
helps
in
this
situation,
but
it
adds
a
lot
of
complexity
for
the
developers.
G
Kind
of
to
address
both
of
those
things,
first
of
all
energy
lines,
production
requirements.
When
you
deploy
a
provider,
interconnect
versus
consumer
to
provider,
interconnect
for
provider
interconnects,
the
number
of
providers
is
relatively
small.
Then
transports
are
essentially
known
in
advance
if
you
are
switching
from
ipv4
to
ipv6
you,
you
tested
in
advance,
and
you
know
exactly
when
you,
so
it's
a
much
less
of
a
problem
way.
You
need
to
dynamically
determine
which,
which
can
basically,
which
networking
need
to
use
to
connect
between
two
providers.
G
On
the
client
side,
you
essentially
don't
know
what
natural
client
is
coming
from.
So
you
know,
existed
solution
for
what's
deployed
right
now,
so
the
deployed
again
clients
distributed
across
multiple
networks
connecting
to
you
without
you,
knowing
in
advance
which
transported
gonna
commit.
So
that's
providers.
The
second
thing
is
outbound
and
not
implement
the
implementing
outbound
I'm
going
to
give.
G
There
are
two
parts
to
that
problem.
The
first
part
is
essentially
outbound
over
UDP,
and
one
of
the
reasons
why
outbound
over
UDP
is
not
implemented
was
not
implemented
as
much
was
because
host-based
natura
verso
for
UDP
worked
fairly
well
for
a
long
time.
So
a
lot
of
people
implemented
that
and
did
not
deal
with
complexity
of
CP
outbound.
G
Wire
TLS
has
not
been
deployed
or
connection
or
eight
and
protocols
have
not
been
deployed
as
much
in
the
large-scale
deployments
just
because
to
scale
it
to
the
same
size
deployments.
The
gdp
will
require
a
lot
more
resources
on
the
service
provider
side
and
the
cost
of
extra
registration
grows
exponentially.
G
Comparing
to
you
so
that's
being
lit,
keeping
people
from
deploying
outbound
with
TLS
and
which
you
have
a
solution.
The
peak
for
the
dual
stack.
It
needs
to
work
with
connectionless
like
UDP
protocols.
The
end
I
think
that's
the
big
problem,
then
just
essentially
not
forcing
people
to
do
outbound
over
TLS
to
solve.
Have
happy
eyeballs
or
to
solve
those
that
deployments
is
I
forcing
that
would
be
a
big
problem
if
they
can
still
do
it
even
without
bound
over
UDP
I
think
that's
still
acceptable
perfect.
Thank
you.
D
Thanks
ollie
Roman,
Allah,
Johansson,
I,
think
you're,
assuming
that
all
server
to
server
connections
or
provider
connections-
that's
not
the
case.
I
hear
your
case
of
providers,
but
there
are
other
server
to
server
connections
where
help
eyeballs
come
in
and
we're
not
discussing
I'll
pan
as
a
solution
for
help
I
balls
for
connection-oriented
protocol,
so
you
TLS
is
more
or
less
old,
but
I
hype
eyeballs
or
see.
The
problem
we
have
a
need
to
focus.
Energy
on
is
UDP
and
to
respond
to
both
you
and
krista.
Here.
D
G
Of
answer
that
are,
first
of
all,
not
all
sim
flows
are
registration
based.
There
are
significant
number
of
deployments,
which,
essentially
just
an
invite
starts,
will
with
the
call
from
the
client
without
the
previous
registration,
so
that
needs
to
be
addressed
as
well,
and
it's
not
being
addressed
by
our
bounces
UDP,
where
you
can
spend
a
significant
amount
of
time
on
the
initial
registration
and
see
not
working
pool
before
you
can
place
an
invite.
The
second
issue
is
again
recovery.
G
If
you're
running
a
single
leg
outbound,
if
that
fool,
fails
essentially
in
a
world
of
cases
because
of
the
time
required
to
find
the
working
flow
and
we
register
your
colon
progress
will
fail
as
well.
All
the
end
customer
will
hang
up,
so
we
losing
it
for
essentially
some
sort
of
a
quick
recovery
mechanism
with
this
one
leg,
one
leg
outbound,
so
that
the
coal
camp,
the
signaling,
can
be
recovered
quickly
enough
in
case
of
either
local
IP,
address
change
or
the
detail
or
the
edge
proxy
failure.
G
H
H
H
You
know
to
the
to
the
end
point
where
you
know,
and
we
don't
really
have
a
good
solution
for
that
with
UDP
right
now,
so
it
seems
like
either
we're
likely
to
need
one
way
or
another
to
find
a
way
to
make
TLS
acceptable
in
this
environment
or
if
that
really
isn't
feasible,
then
maybe
we
need
to
be
figuring
out
how
to
use
sip
over
DTLS.
If,
if,
if
in
fact
that
would
actually
mitigate
any
of
the
problems
with
TLS.
D
Is
you
want
some
again?
I
would
be
in
my
quest
for
deprecating
a
lot
of
old
stuff
I
would
be
happy
to
deprecate
you
to
pee,
but
Roman
wouldn't
accept
that
I
guess
so.
I
mean
let's
stay
focused
on
happy
eyeballs,
trying
to
find
it
the
connection
flow
as
quickly
as
possible,
TLS.
Well
with
happy
eyeballs.
We
have
a
solution
for
all
connection.
Oriented
I,
don't
see
any
problem
there
really
where
we
need
to
focus
again
is
UDP,
and
especially
since
I
mean
outbound,
where
you
have
to
start
with
registering
Roman.
D
If
you
read
it,
documents
isn't
accepted
as
a
solution,
then
we
need
to
find
some
other
solution
and
all
possible
solutions.
We've
seen
so
far
involves
losing
round
trip
times
like
in
TCP.
We
need
to
send
something
funny
strange
and
see
who
responds
quickest
and
then
use
that
connection
for
the
real
request.
If
you
can't
find
if
we
can
find
another
solution,
I
would
be
happy
to
look
at
it.
But
we've
been
discussing
this
for
years
in
the
sip
forum,
ipv6
working
group.
D
We
had
many
many
phone
calls
rounding
this
and
we
discussed
it
in
this
group
and
so
far
we
haven't
found
any
good
slew
without
losing
round
trip
times
and
I.
Think
our
pound
over
UDP
will
solve
many
use
cases
with
desktop
phones,
that
your
stand
there
and
do
registrations
in
the
background
for
sip
clients
and
mobile
phones.
We
have
a
whole
other
set
of
problems
and
we
probably
need
to
discuss
those
issues
where
you
actually
want
to
set
up
the
flow
at
kohls
it
up,
but
then
we're
back
again
to
losing
one
round-trip
time.
F
Carissa,
just
only
you
can
probably
answer,
is
just
for
Crescent
clarification.
What
do
you
get
with
a
one
flow
outbound
that
you
don't
get
by
just
sending?
He
believes.
What's
what's
the
out
want
parts
that
you
need,
because,
in
addition
to
the
keeper
lives
without
point
have
is
this
flow
IDs,
but
those
you're
not
going
to
need,
since
you
only
have
one
flow,
so
what
you
actually
get
from
a
one
flow
outbound
that
you
don't
get
from
just
using
keep
our
lives
just.
D
Using
keep
allies
without
the
keepalive
specified
that
actually
send
their
response.
While
we
can
do
that,
but
that's
still,
we
need
a
response
from
the
server
saying,
I,
understand,
sip,
I,
understand
you
and
we
have
a
working
connection
right.
So
we,
instead
of
registering
like
an
outbound,
we
can
come
up
in
another
solution,
sending
something
that
generates
an
response.
So
we
know
we
have
up
working
sip
server
to
speak
with.
That's
the
whole
idea
with
hyperbole
to
find
something
that
works
right.
F
I
John
the
next.
My
first
point
was
that
I
mean
I
I'm.
I
heard
people
sort
of
vaguely
mentioned
the
server
to
server
case,
but
I'm
still
not
sure
what
solution
people
have
in
mind
since
clearly,
outbound
won't
work
for
that,
because
you're
not
registering
anything-
and
my
second
comment
is
too
is-
is
probably
you
know
shouting
into
the
wind,
but
how
sad
I
am
that
forking
won't
solve
this.
G
Okay,
so
yeah
again,
I
just
wanted
to
kind
of
say
the
same
thing
that
if
working
we're
working
or
at
least
working
and
thumbs,
oh
there
was
a
way
to
a
girl
like
if
you
design
a
registered
to
a
register
or
in
a
coprocessor
to
aggregate
transactions
received
over
multiple
transports.
That
works
quite
nicely.
G
The
other
thing
I
wanted
to
mention,
which
was
related
to
a
single
connection.
Outbound,
what
happens
is
even
what
you
get
some
outbound
when
you
try
to
set
up
the
initial
connection
over
UDP,
you
essentially
trying
to
register
to
register
over
multiple
flows,
so
you
are
like,
even
though
you're
gonna
maintain
a
single
flow
for
outbound,
initially
you'll
end
up
with
multiple
and
what
you
get
from
outbound
a
device
ID.
G
A
A
Are
you
actually
on
again
I
think
I'm
on
okay,
I
thought,
I
heard
your
voice,
so
I
I
had
a
question
around
specifically
you'd
mentioned
that
you
either
thought
that
we
could
not
use
or
we're
trying
to
avoid
request
merging
as
a
solution
to
this,
and
it
seems
to
me
that,
since
we've
taken
the
pain
of
actually
having
that
specified
in
the
protocol
is
it
is
something
that
we
r,
you
just
think,
is
unaesthetic
or
is
there
some
reason
that
it
actually
won't
work?
That's.
E
C
Let
me
fill
in
here:
I
actually
ran
into
a
situation
in
practice
that
had
this
problem
we
had
a
connection.
It
was
actually
a
trunk
between
two
switches
between
two
proxies
that
was
not
particularly
reliable.
It
was
configured
using
zip
colon.
Whatever
the
host
name
was
by
which
I
mean
it
would
attempt
both
UDP
and
TCP.
C
C
It
turns
out
the
request
both
got
there,
so
they
went
through
the
second
proxy.
The
first
prom
request
went
to
the
user-agent
question.
The
user
agent
starts
ringing.
The
second
request
comes
in
it
gets
sent
to
it
gets
sent
to
the
user
agent,
which
is
busy,
and
so
therefore
can
immediately
fails
over
to
the
young
to
the
voicemail
system,
which
is
always
beneficial.
B
A
A
D
You
want
some
coming
back
to
Christus
question.
Why
can't
you
just
send
a
register
or
see?
3263
says
that
for
every
transaction
you
need
to
do
the
dns
lookups.
Your
register
may
end
up
in
another
server.
You
see
another
protocol
down
the
invite
request,
so
you're
not
solving
the
problem
with
the
call
and
the
problem
with
the
call
is
to
focus
because,
as
they'll
said
in
an
earlier
slide,
waiting
up
to
the
default
value
of
32
seconds
before
may
be
failing
over
is
a
usability
problem.
J
D
That's
one
solution,
so
Allah
Johansson
again
the
way
I
discussed
this
with
Gonzalo
at
lunch
was
that
let's
first
shop
off
the
connection,
oriented
stuff
and
write
a
recommendation
on
how
that
fits
in
this
properly.
A
23
page
document
without
much
discussion
then
go
ahead
and
look
at
our
pond
service
route
or
if
we
need
something
else,
because,
as
you
see
here,
that
discussion
will
take
time.
So
let's
pick
these
easy
fruits
and
take
you
to
pee
separately
so.
G
You
give
them
just
a
nip
that
this
is
not
just
DCP
connection-oriented,
so
TCP
TLS
all
can
be
solved
very
easily.
Just
have
a
quick
recommendation
for
people
to
know
how
to
how
to
implement
that
for
anything
connection-oriented
ill
taken,
I
agree.
Udp
is
something
which
needs
to
be
solved
to
as
a
separate
document.
I.
A
G
A
E
As
I've
slide,
so
I
didn't
hop
up,
because
the
way
that
this
slide
was
presented
I,
who
got
the
very
strong
impression
that
the
point
of
the
slide
was
don't
do
that,
so
they
were
felt
no
real
reason
to
hop
up,
but
I
will
call
out
that
reducing
t1
is
probably
not
a
good
idea.
You
can
get
rid
of
the
word
probably,
and
in
fact
you
can
just
say
no,
you
cannot
do
that
to
reduce
t1.
E
It
is
an
error
to
reduce
t
one
on
one
hop
of
a
several
hot
network
that,
where
things
are
actually
running
sup
where
you're
not
running
a
b2b,
you
a
right
if
you're
terminating
your
set
better,
be
a
bu.
A
and
T
1
is
all
one
thing
on
one
side
and
all
something
else.
On
the
other
side,
then
it's
your
problem
is
a
b2b.
You,
a
to
you
know,
figure
out
the
discrepancies
that
you're
going
to
get
the
user
experience,
because
there
are
going
to
be
something
they're
going
to
be
very
bad.
A
So
actually
it
wasn't
that
he
one
thing
I,
believe
that
that
everyone
understands
that
that's
the
not
good
thing.
The
conversations
so
far,
though,
have
actually
discussed
turning
BNF
down
to
a
significantly
smaller
number
of
retransmissions
and
I
by
its
you
know
that
has
some
pretty
strong
implications.
It's.
E
A
proposal
it's
going
to
require
some
analysis.
Yes,
there
are
really
strong
implications.
It's
working
against
themselves
to
trade
off,
getting
things
working
faster
against,
not
getting
things
to
work
when
they
might
have
otherwise
in
a
semi
flaky
network
situation
right
right.
So
if
they,
the
folks
that
are
working
this
want
to
pursue
it,
they
just
need
to
write
very
carefully
down
what
those
trade-offs
are
and
get
an
analysis
of
whether
or
not
they're
actually
going
to
be
worth
it.
Okay,.
A
E
D
Allah
Johansson
I
think
for
me,
this
slide
is
out
of
scope
for
our
Bibles.
This
is
the
problem.
If
you
do
it
seriously
test
one
server.
First,
then
you're
going
to
run
into
this
time
out
and
what
we
want
to
avoid
is
exactly
using
timers.
We
want
to
set
up
the
sessions
in
parallel
and
then
you
can
use
timers,
as
you
always
do
right.
E
J
A
D
D
Some
of
this,
like
upon
light,
may
or
half
a
pound
whatever
we
call,
it
was
something
I
start
to
discussing
for
a
whole
different
set
of
problems
which
is
TLS,
but
then
we
discover
that
well,
it
may
be
one
of
the
solutions
for
UDP
as
well.
I
think
we
need
to
define
up
the
problems
for
you
to
pee
in
a
separate
document.
D
As
you
hear,
I
don't
agree
with
a
long
all
the
details
that
makes
life
fun,
I,
keep
allies
and
low
overhead
naft
I,
don't
really
know
what
he
means
their
next
slide.
Okay,
you
have
to
help
me
here.
Gonzalo
and
TLS.
Light
is
obviously
out
to
scope
for
happy
eyeballs,
but
I
got
a
question
from
Dale
earlier
on
about
that
and
I
think
that's
an
interesting
path
to
go
down
in
this
working
group
and
see
if
we
can
do
anything
anything
that
can
irritate
and
help
us
Traverse
Alex.
D
It's
interesting
and
I
hear
from
Roman
that
people
still
don't
like
TCP
and
TLS,
so
maybe
DTLS
is
a
way
to
something
we
need
to
explore,
but
again
not
related
to
hype.
Eyeballs
I
want
to
keep
hyper
happy
eyeballs
in
scope
and
the
call
transaction
recover
it
well.
There's
something
I
see
constantly
now
in
various
networks,
I'll
also
out
to
scope
for
hype
eyeballs,
but
a
very
interesting
completion
of
the
outbound
project.
I
would
say
so.
Yeah.
A
I
generally
agree
with
with
what
you
said
there
I
think,
especially
the
two
things
in
this
slide
is
something
we
might
want
to
defer
until
we
have
some
concrete
proposals
on
the
table,
but
not
it's
not
part
of
the
happy
eyeballs
work
right.
There
might
be
some
interesting
work
in
this
space
and
as
I'm
looking
through
this
you
know
were
these.
All
of
these
are
actually
stated
in
terms
of
solutions
that
I
think
maybe
a
bit
more
concrete.
Do
we
want
to
think
about
at
the
moment?
It's
you
know.
A
D
A
document
that
describes
the
problem
with
you
to
pee
and
the
possible
solutions
that
we
currently
have
in
our
tool
set
like
service
route
and
upon
and
finds
the
gap,
and
then
we
can
focus
on
the
gap
for
a
while.
It
will
be
very
interesting
discussion,
but
that
needs
some
innovation
and
a
lot
of
good
cups
of
tea.
So
almost
a
requirements
document
that.
A
If
I
think
I
would
like
to
defer
the
conversations
around
the
additional
ancillary
topics
having
to
do
with
DTLS
and
having
do
with
connection
recovery
until
either
those
are
further
along
or
we
have
a
larger
group
of
people
because
I
don't
want
I,
don't
want
like
the
four
of
you
working
on
for
documents
in
parallel,
because
that's
just
that's
never
going
to
make
progress.
I
can.
D
Add
to
this
that
when
we
found
this,
this
was
a
lab
discovery
exhibit
where
we
create
evil
networks,
but
during
the
last
couple
of
months,
actually
have
two
different
customers
and
a
third
one,
not
customer,
but
a
third
development
company
that
actually
called
me,
and
we
have
discovered
these
dual
stack
issues
in
real
life
networks
would
real-life
users
she's,
actually
we're
in
quite
a
hurry
to
get
some
documents
that
I
can
feed
back
to
the
developers
say
now.
Do
this
by.
A
I
John
maddux,
I
mean,
I
think,
the
reason
why
detail
s
is
coming
up
here
is
because
dtls
is
despite
being
connectionless.
It's
for
these
purposes,
connection
oriented
which
so
you
can
do.
You
can
happy
eyeballs
it
by
doing
the
handshake
so
I
mean
you
know
so
I
mean
you
can
do
0r
fut
with
dtls
13.
You
don't
have
to
so
I
think
so
so
that
gives
the
architectural
benefits
of
the
connection
lists.
People
like,
while
still
having
a
pre
handshake
that
you
can
do
experimentally
as
needed
and
I.
A
I
I
G
It's
exactly
what
I
would
answer
as
far
as
scalability
is
comes
from.
Dtls
is
only
slightly
better
than
TLS,
because,
essentially,
primarily
because
of
the
counters,
which
need
to
be
maintained
for
each
message,
which
has
been
sent
both
on
the
client
and
the
server
side.
So
you
end
up
with
fairly
frequently
updated
state
its
and
if
there
is
any
way
to
kind
of
move
those
counters
to
work,
either
sip
sequence
numbers
or
anything
again.
So
it
will
require
some
sort
of
detail
as
modification.
G
A
G
I
A
So
are
there
any
other
aspects
of
this
problem
space
that
we
think
talking
about
would
be
useful
here,
although
you
look
expectant,
no
okay,
all
right,
why?
I
think
we
probably
have
enough
energy
here
to
definitely
move
forward
with
this
work.
I'd
love
to
see
more
discussion
on
the
mailing
list.
I
mean
it's
great.
We
have
a
document
together,
but
just
it
there's
clearly
thought
around
ways
to
address
this.
So
more
messages
and
I
think
that's
probably
it
thank
you.
Everyone
for
showing
up
any
other
business
people
would
like
to
discuss.