►
From YouTube: IETF101-SIPCORE-20180322-0930
Description
SIPCORE meeting session at IETF101
2018/03/22 0930
https://datatracker.ietf.org/meeting/101/proceedings/
B
B
C
Introduce
yourself,
please
yeah.
If
I
hear
you
say
from
my
a
that:
co-author
400
n,
so
M
I'd
like
I'm
here,
just
to
ask
people
to
review
this
document
and
and
probably
back
so
we
haven't
seen
any
any
activity
on
this
document.
So
please
take
a
look
and
if
I
any
comments,
suggestions,
questions
whatever
right.
Thank
you.
So.
B
B
So
we
would
appreciate
you
taking
the
time
to
read
the
drafts,
remembering
that
no
one
will
read
your
drafts.
If
you
don't
read
and
comment
on
some
of
the
else's
drafts,
that's
how
the
process
works
folks,
and
we
would
really
appreciate
it
if
you
would
read
and
comment
on
on.
All
of
these
I
mean
even
the
ones
that
have
been
in
last
call.
D
C
Sorry,
if
I
had
to
go
ahead
a
we
have
another
document
digest
document
and
it's
a
I
think
expiring.
Today,
M
there
was
support
for
this
document.
I
think
I'm
still
receiving
emails.
Talking
about
they're
asking
me
about
this
document,
so
I
it
was
wondering
what
is
the
plan
for
that
document?
Are
we
gonna
ask
the
group
whether
they
are
interested
in
yeah.
B
E
F
A
F
F
So
this
is
just
agenda,
so
here
I'm,
going
to
just
show
a
call
for
showing
the
problem
so
far
so
far,
it's
so
good
you
have.
This
is
a
call
between
a
user
agent
and
an
application
server
going
via
proxy
that
support
session
timer.
You
have
the
invite
going
you
a
indicate.
Support
for
timer
indicates
that
I
want
to
be
the
refresher.
It
goes
to
the
application
server.
The
application
server
since
183,
back
and
and
you
get
an
early
dialog
and
nothing
strange
there.
F
What
is
important
here
and
you
will
see
that
in
a
while
is
that
the
183
doesn't
contain
in
a
session
expires
header
field
because
it's
not
allowed
according
to
RFC
currents.
It's
only
allowed
in
invite,
update
and
and
the
200
ok
responses
to
those.
So
you
don't
have
an
early
dialog
established
here,
but
the
session
timer
negotiation
is
still
ongoing.
Now
then,
the
fun
fun
thing
starts
at
some
point.
F
During
this
early
dialog,
the
application
server
is
going
to
send
an
update
for
whatever
reason
it
is
indicating
supported
timer
here,
and
it
also
reflects
the
the
the
session
timer.
It
indicates.
It
is
the
US
which
is
fine
because
well
actually
it's
not
it's
trying
to
change
the
role.
Who
is
the
refresher?
Because
when
the
invite
came
the
ua
indicated,
I
want
to
be
the
refresher
and
again
the
180
tree
never
contained
a
reply
to
that.
But
now
the
aes,
while
the
session
time
and
negotiate
is
just
negotiation,
is
still
ongoing.
F
It
sends
an
update
where
it
changes
this
body.
It
goes
through
ua,
and
the
first
funny
thing
here
is
that
the
UAE
accepts
it
to
hunter
the
update,
but
it
doesn't
include
anything
session
time
and
related
in
it
now
the
proxy
when
it
receives
this
200.
Ok,
it
is
going
to
insert
a
session
timer
and
it's
going
to
indicate
that
the
refresher
is
the
USC
and
the
reason
why
it's
going
to
do
that
is
yeah
before
we
come
there.
This
text
you
see
here
is
actually
copy
pasted.
F
From
from
from
from
the
RFC
says,
in
a
session,
refresh
request
sent
within
a
dialogue
with
an
active
session.
Timer
takes
the
session
expires.
Header
field
should
be
present
again.
It
is
present
here
in
the
update.
But
the
question
is:
is
the
session
timer
active
because
again
it
hasn't
been
negotiated.
Yet
then,
what
as
I
was
about
to
say
is
that
the
UA
doesn't
include
a
refresher
in
the
updates
response.
F
F
So
in
this
case
the
day
it's
gonna
cause
some
problem,
because
now,
when
the
application
server
receives
this
200
okay,
it
is
actually
going
to
reject
the
whole
invite.
Because
of
this
and
the
session
has
expired.
No
sorry,
this
the
session
establishment
has
failed
and
again
this
is
problem,
and
here
you
can
see
the
whole
flow
in
one
slide.
If
you
want
to
I
see
Paul
is
in
the
queue,
do
you
wanna?
Do
you
want
to
comment
on
on
this
flow
or.
G
G
When
the
update
this
is
sent
by
the
a
s
here
saying
refresher,
equals
UAS
mean
you
AC
in
UAS,
and
in
these
messages
is
relative
to
the
request.
Isn't
it?
And
so,
since
it's
going
in
the
opposite
direction
from
the
invite,
you
know
a
you
a
yet
it's
saying
UAS
is
consistent
with
the
the
property
of
the
prior
invite
that
said,
that
yeah,
you
know
in
the
invite
the
envy
of
the
you
a
was
saying
it
wanted.
G
G
F
G
G
H
I
actually
remember
shockingly
Jonathan
Rosenberg,
who
wrote
the
session
time
for
drought,
but
Steve
Donovan
is
also
so
hey
Paul.
My
my
memory
matches
what
you're
saying
on
what
what
Paul's
saying
about
that?
It's
a
transactional
parameter
for
UAC
and
UAS
like
vaguely
remembering
I
just
did
a
quick
look
and
I.
It
seems
to
be
what
it
says.
So:
yeah
hi
everyone
good
so,
but.
G
F
Think
I
will
double
check
it,
but
I'm
gonna
move
forward,
because
I
think
this
is
because,
like
I
said
there
could
be
a
case
here.
What
app
is
actually
tries
to
change
the
role
and
and
I
think
that
that's
let's
see,
okay,
this
is
trying
to
see
who
we
can
blame
here.
There
were
there's
been
a
lot
of
comment.
For
example,
one
said
not
a
year:
shouldn't
change
the
refresher
role
within
an
internal
Tron
session.
F
Timer
negotiation
is
going,
the
UA
should
not
or
should
include
the
parameter
in
the
update
response,
and
they
should
not
reject
the
invite
because
of
a
session,
timer
ambiguity
and
so
on
and
so
on.
But
I
think
that
this
is
actually
what
RFC
says
today.
It's
not
related
to
this.
What
Jonathan
and
you
just
talked
about,
but
the
RFC
does
describe
the
procedure
from
a
dialog
request.
It
says
I,
don't
think
that
the
procedures
do
not
cover
the
case
when
a
made
dialog
request
is
sent
during
an
ongoing
session.
Timer
negotiation
transaction,
for
example.
F
F
The
problem
is
when
you're,
when
you're
sending
this
update
within
an
ongoing
invite
transaction.
Where
were
you
know
our
negotiation
decision
time?
This
is
actually
the
solution
which
is
currently
in
the
draft,
and
there's
been
a
lot
of
comment
on
that,
mostly
from
poll.
Thank
you
very
much
for
that.
So
this
is
actually
not
something
that
we're
suggesting
tu-tu-tu-tu-tu
I
mean
this
is
how
it's
gonna
be.
We
need
to
change
the
text
so
basically
I'm
gonna
skip
over
this
and
I'm
gonna
skip.
F
It
looked
better
in
my
slides
but
anyway.
So
the
idea
here
is
to
say
that
the
sessions
expires.
Header
can
only
be
included
in
a
session
refresh
request
if
there
is
no
ongoing
negotiation
or
session
time,
a
negotiation,
if
there's
an
ongoing,
don't
don't
include
it
and
their
resources.
Something
saying,
if
there's
a
race
condition
in
this
case,
if
they
a
sense,
an
update
and
it
tries
to
change
this
value
or
even
even
includes
the
value
during
this
ongoing
negotiations
and
the
491
the
request
pending
or
whatever
rejected
the
request.
F
There's
also
been
some
some
some
some
suggestion.
You
know
just
discarded
and
and
and
what
the
problem
is
that
if
you
discard
it-
and
you
may
have
the
proxy
inserting
the
value
anyway,
because
that's
what
RZ
says
and
then
there
was
actually
one
of
the
comments
which
was
said
by
by
Paul.
Was
that
that
the,
if
we
say
the
previous
it
takes,
the
third
bullet
that
you
see
here
is
that
the
previous
text
says
that
if
there
is
no
session
header
expires
today
fill
in
a
response.
It
will
disable
the
session
timer
mechanism.
F
That's
how
it's
written
today,
but
which,
actually
by
mistake,
disable
that
so
it's
not
really
possible.
So
that
text
actually
will
be
removed.
It
should
be
possible
to
to
to
disable
the
session
timer
during
session,
we're
not
trying
to
that
that
for
a
mistake.
But
the
idea
was
here
again
to
say
that
it's
not
possible
to
disable
the
usage
of
session
timer.
While
there
is
an
ongoing
negotiation
of
the
session
timer.
Because
again
we
shouldn't
you
shouldn't,
do
that
you
shouldn't
do
anything
related
to
session
timer,
while
there's
an
ongoing
negotiation
of
it
again.
F
This
is
just
some
of
the
comments.
There
were
more
backup,
slides
here,
I'm
not
going
to
read
through
these.
You
can
see
those
here
this.
This
was
sent
by
Paul,
you
have
to
date
there
and
and
my
reply.
They
were
either
replies
also,
but
I.
Try
to
you
know,
put
the
highlights
here,
something
else
something
else
again.
As
I
said:
I'm
not
really
here
we're
not
going
for
working
route
last
call
or
anything
here.
F
This
is
just
should
I
say
when
when
now
when
c.push,
hopefully
it's
done
and
bundle
is
hopefully
soon
done
more
like
a
reboot,
we
need
to
fix
this.
I
will
read
a
text
and
as
indicated
by
Paul
and
and
and
Jonathan
and
C,
so
that's
all
I
had,
but
basically
they
did.
If
the
comments
or
discussion,
the
focus
should
really
be
on
on
this.
F
F
B
D
I
Go
ahead:
oh
hi,
everybody,
just
my
I
think
the
problem
is
well
stated.
I'm,
not
sure.
I
am
happy
with
the
proposed
solution
in
the
document,
because
my
first
question
would
be:
can
we
just
saw
with
by
enforcing
a
consistent
behavior
on
u-ace
meaning
if
you
are
initiating
a
sip
session
timer,
you
should
be
sending
the
same
like
values
consistently
versus
including
and
not
including
the
session
timer
settings
in
the
issue
in
white
and
note
and
in
node
support,
basically
not
including
it
in
200
a
key
for
an
update
and
as
a
possible
solution.
I
If
one
of
the
UAS
gets
an
inconsistent
session
time,
education
just
started
a
new
update
transaction
use.
Its
obsession
time
refresh
right
after
negotiation,
is
complete.
Instead
of
doing
instead
of
four
kind
of
dropping
the
invite
transaction
or
drop
in
the
dialogue.
I
think
this
is
more
consistent
with
how
sit
session
time
our
place
right
now
in
a
it
probably
will
provide
a
solution
which
works
if
either
one
of
the
UAS
is
implementing
it
and.
F
F
Sure,
and,
and
and
and
as
the
first
bullet
here
says,
also
that
whatever
solution,
we
come
up
with
it's
going
to
have
impact
on
on
existing
deployments,
so
so
I
mean
there
is
otherwise
if
it
was
just
about
clarifying
something
that
would
be
fine
but
but
I
think
we're
gonna
have
to
add
some.
Some
master
must
not
see
in
the
document
then,
and.
J
Yeah
Roland
just
get
here
to
telecom
I,
think
the
discussion
we
had
around
the
session
timer
I
think
that
the
focus
is
well-defined.
What
we
are
looking
for,
the
most
important
is
what
going
to
to
Roman's
comment
that
we
don't
have
too
many
messages
with
regard
to
the
user
agent
itself.
So
if
we
have
a
final
negotiation,
that's
it
so
and
wait
for
for
the
Refresh
after
sometime.
D
B
J
G
Just
wanted
to
respond
back,
you
know
the
claiming
that
there's
some
distinction
between
a
UA
and
a
s,
Simms
red
herring
to
me
I
mean
look
at
this
me.
You
say
we
only
do
with
session
timer
with
a
s's
or
something
well
note
that
the
session
timer
had
to
be
initiated
by
the
UA
I
mean
at
least
in
this
case.
It
was
initiated
by
the
you
way,
and
so
you
know
you
I
didn't
necessarily
know
it
was
calling
it
a
s,
so
I
mean
I,
think
that's
a
whole
red
herring.
B
G
My
original
proposal,
I
mean
I,
am
I,
mean
Krister
actually
has
my
original
a
couple
of
different
proposals.
You
know
in
here
up
at
the
beginning,
my
initial
thought
was
just
to
you,
know,
ignore
and
then
yeah
I,
don't
think
I
like
that
I
mean
I,
I,
think
not
having
the
the
update,
that's
embedded
in
and
invite
not
carry
the
session
expires.
G
F
B
You
know
everybody's
agreeing
and
we're
where
the
problem
lies
and
at
least
understands
what
we're
saying.
We
understand
what
we're
saying
about
solutions
right,
yeah
we've
got
more
than
one
solution.
We
should
do
that
on
the
list.
I
think
that
we
don't
have
them
here
and
I,
don't
think
trying
to
accomplish
that
is
worthwhile.
B
B
B
I
Ahead,
yeah
just
to
comment
even
with
Chris
resolution
and
again
I,
don't
I
don't
want
to
differentiate
between
application
server
versus
QA
they're.
Just
you
ace.
As
far
as
the
obsession
timer
is
concerned,
there
is
I,
don't
think
there
is
a
solution
which
which
can
be
implemented
without
change
into
the
UAE's.
It
will
affect
something
or
somebody
in
and
so
saying
that
again
asking
us
to
be
consistent.
That's
all
affect
us,
ignoring,
update
within
invites
will
affect
some
of
the
UAS
because
they
will
essentially
take
down
this
obsession
timer.
F
I
Again,
with
proxies
is
very
like
we
cannot
force
noose,
obsession
time
or
negotiation,
they
cannot
start
new
transactions,
so
it's
very
limited
things
can
be
done
for
proxies,
so
I
don't
think
it
can
be
fixed
from
there,
but
again
it
it
does
bring
a
whole
new
set
of
problems
and
again
there
are
possible
solutions,
but
I,
don't
think
we
it's
possible
to
have
a
bear.
It's
compatible
solution
without
affecting
one
of
the
without
affecting
us.
Okay,.
B
So
what
I
ask
is
that
we
have
this
discussion
on
the
list,
let
that
you
know
everybody
try
and
work
together
and
try
and
compromise,
or
you
know,
seek
each
other's
point
of
view
pick
a
direction.
Let's
get
the
text
right
and
get
the
document
done
and
there's
I.