►
From YouTube: IETF110-ASAP-20210308-1600
Description
ASAP meeting session at IETF110
2021/03/08 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
A
A
All
right,
we
have
confirmation
that
when
the
participants
could
hear
us
all
right,
you
want
to
go
ahead
and
move
the
slides.
A
A
A
A
All
right
so
some
info
on
how
we're
going
to
be
running
the
session,
so
any
decisions
that
we
make
will
be
confirmed
on
the
mailing
list.
The
meeting
is
being
recorded.
If
you
are
at
the
mic.
Please
use
headphones
when
speaking
to
cut
out
issues
such
as
echo.
A
A
We've
got
some
resources
here
on
how
to
work
with
these
working
group
sessions
down
at
the
bottom.
If
you
need
help
with
working
with
meat,
echo.
A
A
A
A
B
A
A
A
So
I
see
in
the
chat
room,
we
have
a
question.
Is
there
anybody
actually
here?
So
I
have
a
participants
list
of
23
people,
so
I
I
see
some
people
who
are
not
just
chairs
ads.
B
Or
medica,
so
it
looks
like
we've
had
two
volunteers,
costa
who's,
one
of
the
co-authors
he's
willing
to
while
he's
not
speaking,
he's
willing
to
take
minutes
and
mark
pittitugano
is
also
willing
to
take
notes.
A
Cool,
thank
you
very
much
and
again
you
could
use
a
cody
md
or
if
you
would
like
to
take
notes
offline
and
send
them
to
the
chair
separately.
That
also
works.
I'm
we're
good
with
either.
A
A
A
So
I
think
at
this
point
the
presenters
enter
the
queue
and
then
they're
allowed
to
talk.
A
There
we
go
so
shri,
kant,
just
click
your
mic
and
video
icons,
and
you
should
be
good
to
go.
A
C
C
All
right,
so
this
is
the
agenda.
We
can
go
to
the
next
slide.
C
Okay,
great
so
right
so
for
the
benefit
of
those
who
are
new
here
and
you
know
for
whom
asap
is
a
new
thing
and
haven't
had
a
chance
to
go
through
the
draft.
I
just
wanted
to
cover
the
problem
in
a
couple
of
minutes
that
we're
trying
to
solve
here.
We
presented
this
back
in
ietf
106..
C
So
it's
been
some
time
and
I
thought
this
would
be
a
good
refresher,
so
yeah,
so
today,
administrators,
usually
when
deploying
you
know
their
sbc
or
any
other
equipment
that
peers
with
the
service
provider
and
they're
setting
up
the
sip
trunk,
they
have
a
tedious
job
of
you
know,
fixing
interoperability,
issues
and
things
that
should
take
them.
C
You
know
just
a
couple
of
minutes,
end
up
taking
them
a
few
hours
and
even
a
few
days
in
fact,
and
they
end
up
having
to
open
service
requests
with
vendor
equipment
manufacturers,
as
well
as
a
service
provider,
in
order
to
get
these
problems
fixed.
So
what
we're
trying
to
do
is
to
bring
that
pain
down,
and
you
know
just
get
this
get
zip
calls
up
and
running
in
a
few
minutes
next
slide.
Please.
C
Right
so
the
first
thing
we
need
to
find
out
was:
you
know
how
big
is
the
problem
right,
so
we
went
back
to
our
support
cases
on
this
is
the
cisco
cube,
which
is
the
which
is
cisco's
enterprise
sbc,
and
we
found
out
that
around
22
of
the
cases
directly
relate
to
in
itsp
interoperability
issues.
So
cisco
is
just
one
of
the
sbc
manufacturers
here
there
are
many
of
them
in
the
market,
so
you
can
imagine
how
many
you
know.
Service
requests
are
getting
created.
C
How
many
problems
are
there
that
need
to
be
solved?
So
it's
quite
a
lot
there,
and
apart
from
that,
you
also
have
a
significant
number
of
enterprises
that
are
still
on
analog
and
digital
telephony
and
are
gradually
moving
on
to
sip
trunks
right.
So
this
problem
isn't
going
to
go
away.
We're
going
to
see
this
problem.
You
know
for
the
next
few
years,
at
least
next
slide.
Please.
C
Right
so
I
quickly
wanted
to
walk
through
the
high
level
overview
of
what
the
draft
proposes.
So
for
the
purpose
of
this
diagram,
we've
got
an
enterprise
sbc,
that's
sitting
right
in
the
center
and
a
capability
server,
that's
sitting
on
the
service
provider
network,
so
the
capability,
so
the
svc
will
send
a
http.
C
Right,
so,
what's
inside
that
capability
set
document,
a
a
representation
in
xml
of
you
know
a
yang
model,
that's
being
proposed
in
the
draft,
we're
still
not
sure
whether
we're
going
with
the
xml
or
the
json
right.
So
right
now
we're
just
representing
this
in
xml,
but
the
final
call
is
yet
to
be
taken
and,
as
you
can
see
here,
we
are
covering
various
facets
of
the
call
setup
process.
You
know
what
are
the
transport
characteristics
that
are
required
for
the
call?
What
are
the
media
requirements
for
the
call?
C
C
Right
so
the
story
so
far
so
versions,
one
and
two
we
published
before
we
presented
at
ietf
106
and
at
the
dispatch
meeting
at
itf
106,
we
had
a
consensus
to
form
a
mini
working
group,
and
last
year
we
got
a
charter
proposed,
which
was
approved
as
well
as
the
working
group
work
group
that
was
formed
late
last
year
in
august
of
2020
next
slide.
Please.
C
Right
so
I
just
wanted
to
quickly
go
through
the
various
changes
that
you
know.
The
draft
has
undergone
over
the
last
year,
so
versions.
One
and
two
like
I
mentioned
they
were
the
initial
draft,
just
a
name
change
and
some
formatting
issues
that
were
fixed
in
version
three.
We
added
the
insert
location
field
to
the
capability
set.
This
is
for
deployments
where
the
enterprise
and
the
service
provider
want
to
do
sip
over
tls,
and
you
know
you
need
the
required
configuration
for
that.
So
that
comes
under
the
third
location
field.
C
C
Right
and
then
we
come
to
the
latest
version,
so
in
the
latest
version
we
clarified,
you
know
whatever
http
versions
that
are
supported,
which
is
version
1.1
and
above
we
also
define
the
scope
of
the
work
in
the
draft.
So
basically
we
did
not.
We
do
not
include
any
low
level
details
such
as
ip
addressing
scheme
and
the
net
access
network
infrastructure,
so
that
part
of
the
that
part
is
not
covered
by
the
drop.
The
draft
is
just
about.
C
How
do
you
get
sip
calls
working
with
rtp
between
the
enterprise
and
the
service
provider,
and
then
we
also
had
a.
We
also
added
a
paragraph
that
clarifies
on
how
the
workflow
is
going
to
work.
In
case
you
have
an
intermediate
service
provider
between
the
enterprise
and
the
service
provider,
because
what
we've
observed
is,
if
you
have
an
enterprise,
that's
trying
to
peer
with,
let's
say
service
provider
abc
often
that
connection
goes
via
a
service
provider
xyz.
C
C
Right
so
this
brings
me
to
the
open
issues
that
are,
you
know
yet
to
be
finalized
upon
in
the
draft,
so
one
one
was
the
xml
or
the
json
representation
for
the
capability
set.
Another
very
important
aspect
is
the
discovery
of
the
capability
server,
which
is
sitting
in
the
service
provider
network.
We
would
like
this
to
be
an
automated
process
instead
of
having
the
administrator
go
ahead,
and
you
know
configure
that
on
the
sbc
and
point
that
towards
you
know
the
capability
server.
C
We
would
like
this
to
be
an
automated.
You
know
process.
So,
for
example,
web
finger
is
one
of
the
frameworks
that
can
be
used
here
for
the
discovery,
and
we
wanted
to
ask
the
larger
group
if
there
are
any
other
parameters
that
needed
to
be
added
to
the
capability
set,
and
you
know
if
there
are
any
modifications
that
are
required
in
the
draft.
We
got
a
review
today
from
mark
which
was
really
helpful.
C
C
Specific
section,
so
I
think
those
are
two
really
good
points
that
he
raised
thanks
mark
and
you
know
we
will
address
those
in
the
upcoming
upcoming
versions
of
the
draft
and,
if
you've
noticed
that
the
capability
set
encompasses
all
of
the
vendor
agnostic
parameters
that
we
really
think
are
important
to
get
sip
calls
working,
but
we
are
definitely
open
to
hearing
from
the
larger
group
on
anything
that
we've
missed
and
anything
that
would
be
more
helpful
to
you
know
make
this
a
more
seamless
process,
and
finally,
just
I
just
wanted
to
ask
the
group
if
you
know
this
draft
is
good
now
to
be
adopted
by
the
working
group
as
well.
C
Yeah
thanks
gene
thanks
gonzalo.
That's
all
I
had.
A
All
right,
thank
you
all
right,
so
cue
is
open
if
anybody
wants
to
come
to
the
the
mic
with
any
questions
or
comments.
A
A
A
A
B
Hey
gene,
I
I
don't
see
the
show
hands
tool.
Let
me
stop
sharing
and
see
if
that
helps.
A
Did
let's
see,
oh
so
in
the
chat
room,
I
hear
got
nothing
for
him
showing.
B
A
So
so
some
people
were
able
to
show
their
hands.
A
A
A
B
A
A
Okay,
so
I
I
guess
it's
showing
both
of
the
raised
hands.
I
should
have
disambiguated
them,
so
the
one
with
the
higher
number
of
raised
hands
was
the
second
one
that
I
ran.
A
So
you
should
now
see
a
second
question.
Should
the
working
group
adopt
the
draft
as
a
working
group
item?
Oh
wait,
somebody
said
maybe
oh,
we
have
john
peterson
in
the
queue.
Sorry.
D
A
This
is
true,
there
is
not
another
alternative.
Unless
somebody
stands
up
and
says,
hey,
I
got
another
draft,
but
we
will
be
confirming
this
decision
on
the
mailing
list.
A
What
I
see
here
is
that
we've
got
eight
people
have
well.
We
should
be
vote
voting
like
this,
but
there
is
support
for
adopting
the
draft
and
we
will
confirm
this
on
the
list.
A
Is
there
any
other
comments
or
questions
anybody
like
to
come
to
the
queue.
E
Hello,
we
we
can,
we
can
hear
your
costume
okay
great.
I
I
just
wanted
to
tie
back
it
to
the
point
that
shri
khan's
raised
with
regards
to
store,
we
j.
We
I
mean,
I
think
all
all
of
us
in
you
know
the
co-authors
basically
feel
that
stir
from
the
perspective
of
enterprise
and
service
provider,
networks
is
going
to
play
a
pivotal
role
and
we
must
have
something
that
is
specific
to
store
as
far
as
this
framework
and
this
graph
is
concerned.
E
I
think
we
can
incorporate
elements
of
that
into
into
the
asap
effort,
but,
from
the
perspective
of
you
know
fleshing
out
a
framework
and
a
draft
that
has
all
the
elements
to
it
that
are
that
are
required
from
an
enterprise
to
service
providers,
ship
trunking
scenario.
We
definitely
feel
that
you
know
something
related
to
stove
would
be
of
great
importance,
so
I
just
wanted
to
highlight
that
aspect
as
well.
F
Ahead
hi,
can
you
hear
me?
Okay,
probably
yes,
just
to
respond
to
what
was
just
said
about.
F
I
think
that
it's
true
that
we
are
far
from
from
having
a
mechanism
for
a
delegated
certificate
in
store,
but
it
does
not
prevent
to
start
doing
the
work
in
this
draft
and
then
a
solid
solution.
If,
at
the
time
where
this
draft
is
read
ready,
but
we
still
do
not
have
all
the
mechanism
in
place,
we
can
split
it
and
do
an
extension
separately,
but
I
don't
think
that
prevents
to
start
doing
so.
E
Yeah,
I
I
just
wanted
to
you
know
just
to
say
that
I
kind
of
agree
with
what
mark
brought
up,
so
we
will
basically
see
how
how
you
know
the
store
effort,
plans
out
and
the
timelines
of
that
and
we'll
decided
the
best
approach
possible.
Whether
we
need
to
embed
something
with
regards
to
stuff
within
this
draft
or
or
propose
an
extension
as
when
some
of
the
store
stuff
becomes
mature
and
all
of
the
all
of
the
cogs
to
that
framework
have
been
ironed
out.
G
Hey
guys,
so
you
know
I'm
obviously
supportive
of
moving
forward.
The
draft
couple
comments.
One
is
casa,
been
everyone.
I
have
a
draft
in
a
similar
area
at
this
ietf
meeting
that
talks
about
high
availability,
be
on
sip
trunks.
There's
some
overlap
actually
in
the
configuration
data.
There's
a
configuration
mechanism
defined
in
my
draft
as
well.
So
I'd
encourage
you
guys
to
take
a
look
at
that
and
I'm
happy
to
collaborate
on
it
and
then.
The
second
comment
is
on
the
actual
elements
in
the
in
the
yaml.
G
I
like
to
me:
there's
there's
two
very
different
types
of
stuff
in
there,
there's
stuff
that
the
sbc
and
the
receiving
end
probably
knows
about
and
can
easily
create
the
configuration
file
from
it
and
then
there's
the
stuff.
That's
a
little
harder.
The
num
range
was
the
one
in
particular
that
struck
me
as
as
quite
a
different
story,
and
that
relates
to
the
stir
stuff.
So
my
question,
slash
feedback.
G
Is
you
know
to
minimize
the
scope
of
the
document
to
only
be
that
which
can
easily
be
implemented,
meaning
the
terminating
spc
and
the
carrier
side
can
basically
generate
this
document
trivially
from
its
configuration
and,
if
it's
more
than
that,
then
push
it
out
of
scope
for
now,
so
that
this
can
actually
get
implemented
and
deployed.
That's
my
main
feedback.
B
Jonathan,
hey
jonathan
one,
quick
question,
though
for
jonathan
I
I
saw
the
draft
that
you
put
forward.
I
haven't
read
it
but
is,
is
it
problematic
overlap
or
is
it
complementary.
G
It's
mostly
complementary,
I
mean
it
just
needs
to
be
reconciled.
The
the
bulk
of
the
draft
is
more
on
the
aha
mechanisms
and
it
requires
a
configuration
of
the
set
of
ip
addresses
of
the
clusters
in
the
instance,
and
so
that
piece
defines
a
json
document.
You
fetch
vhtp,
so
I
mean
it's
just
a
question
of
making
sure
that
these
things
line
up
and
they're
either
in
you
know,
do
you
think
so
I
so.
I
think
it's
mostly
complementary
and
we
just
have
to
reconcile
these
two.
B
G
Yeah
did
you
I
I
was
quickly
trying
to
scan
through.
Is
there
something
in
the
draft
that
enumerates
the
ip
address
set
for
the
the
carriers?
Does
that
call
controlled.
G
Yeah
so
I'll
I'll
send
comments
on
the
list.
Basically,
it
overlaps
with
the
call
control
field
in
the
ammo
file.
So
we
either
need
to
bring
the
the
couple
additional
parameters
in
my
draft
into
this
or
or
something
like
that,
it's
probably
the
right
thing:
okay,
yeah
yeah,
just
okay,.
B
E
Hey
jonathan
nice
to
see
you
here
so
with
with,
with
regards
to
your
comment
on
you
know:
kind
of
simplifying
stuff
for
service
providers
so
that
it's
actually
deployed
and
adopted.
I
I
agree.
I
certainly
would
be
very
difficult
for
a
service
provider
to
keep
track
of
the
drd
range
for
every
single
enterprise
that
registers
in
I
I
was
thinking.
Probably
it
would
probably
make
sense
to
make
that
specific
parameter
optional,
as
opposed
to
remove
it
all
together
that
that
was.
G
Where
I
was
leaning
my
sense
again,
it's
like
you
know,
keep
it
simple
and
you
know
perfect
is
the
enemy,
the
good,
I
think,
there's
gonna,
there's
no
shortage
of
of
stuff
being
worked
on
around
passing
around
phone
numbers
and
how
we
convey
them
as
it
relates
to
some
of
the
store
stuff
too.
I
think
you
just
yank
it
you
can.
You
can
always
extend
it
later,
but
get
this
thing
done,
and
and
this
way
you
don't
have
to
worry
about,
reconciling
with
all
that
other
stuff.
A
Thanks
cullen,
please
go
ahead.
H
I
just
had
to
unmute
a
few
times
and
I
finally
got
there
so
just
sort
of
on
the
comment
of
that
number
range
stuff.
H
I
I
feel
like
there's
sort
of
like
you
know,
there's
sip
trunks
that
are
meant
for,
like
a
you
know
like
like
a
call
center
to
a
lot
to
a
bunch
of
different
large
carriers
or
they're,
very
different
from
one,
that's
for
a
small
pbx
and
a
small
business
up
to
up
to
a
service
provider,
and
so
maybe
we
just
we
probably
need
to
talk
a
little
bit
more
about
those
than
where
the
number
ranges
make
sense.
H
In
certain
cases
I
mean
for
the
small
pbx
case,
then
the
carrier
is
allocating
a
very
specific
number
range
and
it's
very
well
known,
and
it's
you
know
it's
generally,
like
you
know,
here's
your
50
numbers,
so
I
I
I
think
we
probably
went
thinking
more
back
about
those
drafts.
We
probably
just
weren't,
really
clear
enough
about
what
these
all
were
and
when
you
used
them
when
they
were
optional
when
they
made
it
and
whether
they
helped.
I
mean
like,
let's
not
put
stuff
in
here-
that's
not
needed
right.
H
A
Thank
you,
john
peterson.
Please
go
ahead.
D
Yeah
I
mean
I
was
kind
of
wondering
like
how
automatable-
and
this
is
part
of
that
conversation
you
know
really
are
like
telephone
numbers.
Like
I
mean
it's,
you
know
if
an
enterprise
gets
a
block
of
like
50
telephone
numbers
is
the
assignment
of
those
numbers
automatic
like
too
arbitrary.
I
guess
is
my
point
or
you
know
I
mean
if
you're
only
learning
about
what
telephone
numbers
you
got
from
like
in
you
know,
auto
config
with
the
service
provider,
like
surely
there's
some
like
manual
interventionists
to
follow
that
right.
D
So
I
mean
I
guess
this
is.
This
is
why
I
I
think
I
might
be
with
jonathan
on
this
and
that
I
can
imagine
you
know,
use
cases
where
this
might
make
sense,
but
like
it's
not
like
dcp
or
just
doesn't
matter
what
numbers
you
get
right.
G
Yeah
and
and
to
call
on
me
my
point
is
not
that
there's
too
many
numbers,
it's
that
it
john
makes
another
great
point,
which
is
the
enterprise,
probably
needs
to
take
manual
steps
once
they
get
the
numbers.
My
point
is
the
service
provider.
Even
if
it's
one
number,
I
would
be
skeptical
that
it
is
very
easy
for
a
service
provider
to
implement
some
software
that
magically
produces.
That
number
in
response
to
the
http.
Get
request
to
get
this
document.
G
Because
again,
the
implementation
model
I
have
in
mind
is
like
okay,
you've
got
a
carrier,
they've
got
an
sbc,
it's
terminating
the
call
someone's
typed
in
the
config
into
the
cli
on
this
svc.
The
phone
numbers
are
stored
elsewhere
and
I
don't
know
where,
and
it's
probably
a
disastrous
mess,
and
maybe
even
the
spc
doesn't
know
them.
So
the
spc
could
serve
the
http,
get
request
for
the
rest
of
this
document,
but
not
for
the
phone
numbers
at
least
not
easily,
in
my
opinion.
G
H
Well,
there's
one
thing
that
the
spc
does
know,
and
that
is
which
incoming
sip
requests
it
routes
down
this
sip
trunk
and
it
uses
the
phone
number
to
do
that
generally.
So
I
I
I
don't
know
I
mean
I,
I
think
we
have
to
dig
around
this.
I
totally
agree
with
peterson's
comment
that
it's
not
just
like
this
is
not
like
dhcp.
G
H
Definitely
the
case
right
colin.
That
is
not
how
mine
works
actually,
so
that
wouldn't
work.
No,
but
that's
what
I'm
talking
about
the
ones
for
small
business
sbcs.
It
would
be
how
yours
work
right.
Like
I
mean
how
else
would
an
sbc
possibly
work
that
was
serving
sip
trunks
to
a
small
business
for
incoming
costs,
and
that's
why
I
said
I
differentiated
these
two
cases,
but
for
that
case
right,
like
the
microsoft
small
business,
what
was
the
sip
connect
spec
like
all
of
that
stuff
right
like
that
stuff
yeah,
it
does
sort
of.
G
Know
right,
it's
configured
as
a
trunk
group
parameter
in
the
cpuri
as
opposed
to
an
actual
phone
number.
I
mean
the
phone
number
might
be
in
the
cpr
itself
and
the
like
the
two
or
request
your
eye,
but
but
it's
but
the
the
thing
that
knows
like
determines
where
to
send
the
call
is
possibly
based
on
upstream
trunk
group
definitions.
That's
how
we
do
it.
For
example,.
H
H
We're
talking
about
for
the
this
that
that
case
and
what
I
don't
think
the
draft
makes
any
of
that
at
all
clear
right.
I
just
I
just
think
that
that's
like
I'm
not
even
saying
we
need
that
in
the
draft.
I
have
no
idea
what's
needed
or
not
needed,
but
it
just
seems
like
that
that
people
were
thinking
of
a
different
use
case
than
the
type
of
then
sip
trunks
that
were
for
outbound
calls
are
very
for
very
generic
termination.
C
Yeah,
I
think
when,
when
we
were,
you
know
putting
in
the
that
particular
field.
What
we
were
thinking
about
was
a
specific
use
case
where
sometimes
what
we've
observed
is
when
an
enterprise
doesn't
sorry
yeah
when
an
enterprise
doesn't,
you
know,
send
the
right
phone
number,
it
gets
rejected
by
the
service
provider
so
because
the
service
programs
provide
us
pretty
strict
about
what
kind
of
numbers
are
being
advertised
by
the
enterprise.
So
that
was
the
sort
of
you
know
use
case
that
we
had
in
mind,
but
yeah.
C
I
think
it
it
makes
sense
that
if,
if
it
does,
if
it's
a
mess-
and
it
does
make
it
more
complicated,
then
it
could
be
something
that
you
know
we
could
amend
in
the
draft
yeah.