►
From YouTube: IETF100-SIPCORE-20171113-1740
Description
SIPCORE meeting session at IETF100
2017/11/13 1740
https://datatracker.ietf.org/meeting/100/proceedings/
B
A
A
A
A
We'll
have
some
short
discussions
of
see
if
we
can
move
them
forward
and
then
we
have
a
session
on
push
with
Krister
and
that
that's
any
discussion
of
the
agenda.
I
do
have
a
scribe.
Thank
you.
Very
much
could
use
a
note-taker
could
use
a
jabber
scribe.
Is
there
someone
in
the
jabber
room
not
expecting
a
lots
to
go
on
in
the
Java
room
today?
But
if
there's
somebody
in
the
jabber
room,
I'd
appreciate,
if
you
describe
for
us,
if
somebody
can
do
that,
okay
yeah,
you
shouldn't
be
both.
C
A
A
Drafts
so
I've
talked
to
the
author
of
C
div
and
they'd
like
to
work
in
group
last
call
it
I
think
it's
ready
to
go.
It's
been
hanging
around
for
a
while.
I
probably
will
want
to
get
some
people
to
do
we
chairs
and
want
to
get
some
more
reviews.
Don't
so
we'll
want
to
get
people
up,
but
anyone
not
gonna
object
to
starting
working
group
laugh,
call
and
seed
it
pretty
soon.
D
A
A
A
A
D
A
F
A
F
F
B
G
Okay,
next
slide,
please,
okay!
So
in
some
context
of
this
work
there
is
a
that
a
76
16,
a
it's
an
update
to
that
HTTP
digest
mechanism.
It
did
the
update
few
aspects
to
to
that
mechanism.
They
added
the
few
algorithms
kept
md5
as
a
backward,
a
compatibility
algorithm
but
added
a
char
to
56
as
the
default
algorithm,
a
mandated,
the
use
of
QP
a
parameter
and
they
create
an
Dianna
registry
for
new
algorithms.
Next
slide,
please.
G
So
the
idea
of
this
draft
is
just
to
follow
what
was
done
with
that
with
that
HTTP
digest
mechanism
just
use
the
same
algorithms
update
the
zip,
a
a
B
in
F
and
and
follow
the
same
recommendations
next
slide.
Please
a
last
time
we
discussed
this.
There
was
some
discussion
about
for
King
and
how
we
want
to
handle
that
so
a
and
the
feedback
was
just
keep
it
as
it
is,
don't
change
anything
led
there,
the
proxies!
G
That's
a
proxy,
just
aggregate
those
into
a
single
response
and
expect
the
client
to
provide
a
responses
to
those
to
those
challenges.
Next
slide,
please!
So
a
this!
This
has
been
there
for
some
time
and
I
think
I'm.
Sorry
I
think
it's
it's
ready
like
it's
yeah,
I
I,
don't
I'm
now
aware
of
any
open
issues
and
I'm.
G
Actually
there
was
one
suggestion
for
a
adding
some
internationalization
to
to
this
document.
I
didn't
see
anybody
interested
in
that.
So
we
said:
okay,
no
interest
on
I'm,
not
gonna
work
on
that.
So
my
question
is:
are
there
any
open
issues
of
this
document
that
people
are
aware
of
it
and
if
not,
can
we
adopt
this
as
a
workgroup
document.
C
Welcome
back
to
agitator
come.
Do
you
earlier
really
think
that
an
updated,
HTTP
digest
authentication
will
be
implemented
by
anyone?
I
remember
like
12
years
ago
there
was
a
proposal
to
do
a
proper
digest
for
a
soup,
and
even
then
it
was
rejected
simply
for
the
reason
you
can
use
TLS
and
basic,
and
it's
I
said
it's
more
secure
than
using.
G
C
G
C
A
G
G
G
G
H
G
Slide,
please,
okay,
so
just
some
context
about
this.
So
this
is
a
mechanism
that
we,
when
I,
allow
a
user
agent
to
use
non
credentials
to
get
access
to
sip
services,
and
this
would
enable
a
single
sign-on
sign-on
feature
where
the
user
expected
to
use
one
one
set
of
credentials
to
access
sip
and
non
sip
services.
Next
slide,
please
so
similar
to
the
earth
or
see
the
which
defines
two
types
of
clients.
G
A
one,
confidential
and
public
came
a
clients
here
we're
talking
about
a
confidential
UA,
which
is
a
user
agent
that
is
capable
of
maintained
in
maintaining
the
security
of
that
a
of
the
credentials
and
tokens
they
provided
it
to
that.
To
that
user
agent,
public
M
a
UA
is
it
can
now
guarantee
that
next
slide
please.
So
there
are
few
use
cases
that
they
are
discussed
and
in
in
this
draft,
so
there
is
a
and
what
what
comes
into
play,
also
that
the
user
interface
on
those
devices
for
this.
G
In
this
specific
use
case,
we
were
talking
about
public
UA
with
rich
UI,
so
the
public.
You
cannot
keep
those
tokens
in
locally,
so
it's
gonna
be
handed
to
the
proxy
only
to
handle
that.
So
in
this
case,
in
the
use
cases
the
user
daily
tries
to
register
it
gets
rejected
because
there
is
no
credentials.
There's
a
location
head
of
here
and-
and
this
this
is
one
of
the
open
questions
that
we
have
we'll
discuss
later
on
in
the
user.
G
So
in
this
use
case,
there
is
a
public
UA,
but
it
has
very
limited
UI
in
this
case
we're
talking
about
a
user
that
has
access
to
you,
a
phone
and
a
user
agent
to
in
a
browser,
so
the
user
agent.
That
user
will
go
to
that,
a
to
the
browser
and
login
into
that
authorization
server
and
obtain
a
short-lived
numeric
access
code
and
then
we'll
punch
that
that
code
into
the
user
agent
that
will
be
collected
and
and
sent
in
the
registration
request
to
a
proxy.
G
The
proxy
will
exchange
that
for
tokens
and
okay,
okay,
the
registration
and
again
at
the
end.
We
have
that
shared
key.
That's
created
extra!
Please
now
that
Shift
key
is
used
to
kind
of
allow
the
user
agent
to
re-register
or
establish
a
communication
with
the
proxy
if
that
connection
fails
for
some
reason,
so
without
really
requiring
the
user
to
provide
his
credential
again,
obviously,
that
the
proxy
can
invalidate
that
key
anytime
and
require
the
user
to
go
on
and
validate
itself
or
authenticate
and
validate
self.x
like
these.
G
In
this
case,
this
is
a
confidential
UA
would
rituai
that
the
user
agent
goes
directly
to
the
authorization
server
using
the
authentication
mechanism.
Existing
mechanism,
which
is
outerscope
obtains
access,
token
and
then
register
uses
that
access
token
the
proxy
could
could
add
an
introspection
step.
This
is
an
optional
and
then
okay.
Is
that
a
that
registration
in
this
case
that
it
is
no
need
for
shared
token,
because
the
user
agents
already
have
access
to
the
access
token,
so
it
will
use
that
all
the
time
next
slide.
Please.
G
Okay,
so
I
have
a
few
open
issues
that
I
hoping
to
get
some
feedback
here
in
one
use
case
we're
talking
about
401
with
location
Heather.
There
is
no
location
header
currently
defined
in
Sep,
so
there
is
a
allocation
either
for
HTTP,
so
I'm
kind
of
suggesting
we
do
something
like
that,
so
indicate
that
they're
authorized
server,
and
so
that's
I
would
like
to
get
some
feedback
from
here.
If
that
that
makes
sense
or
if
there
are
others,
other
suggestions,
a
that
proof
position.
Calculation
and
we
use
that
I.
G
Just
think
that
is
defined
by
a
44
74
is.
Is
that
reasonable?
Any
anybody
has
any
any
other
suggestions
if
that,
if
they
or
if
there
is
any
problem
with
that
and
for
now
we
use
that
GOP.
If
for
real
registrations,
is
that
do
we
need
to?
Is
that
do
we
recommend
to
use
that
for
all
requests
from
the
user
agent
to
to
the
proxy
or
just
keep
it
limited
to
to
the
registration?
So
so
these
are
kind
of
they're.
The
open
issues
that
we're
hoping
to
get
some
feedback
here.
C
Both
comes
back
having
it
did
review
again.
John
Peterson
try
to
standardize
something
like
this
couple
of
years
ago.
He
still
tries
to
standardize
this
under
the
guise
of
in
this
table
working
group
and
under
the
guise
of
providing
secure
originating
numbers
which
doesn't
work
in
my
opinion,
but
it's
basically
a
third
party
authentication
scheme,
and
this
can
work
and
it's
interesting
work
but
I
guess
there's
a
big
overlap
between
your
proposal
and
proposal
of
John
Peters
and
in
his
various
drafts
over
the
last
couple
of
years.
So,
yes,
I,
think
that's
useful
work.
A
A
E
G
E
E
So
why
not
a
fourth
so
so
I
mean
the
other
reason
I
thought
of
that
is
because
being
a
you
can
see
it
getting
an
increasing
amount
of
gray
in
my
beard
here
in
the
early
design
of
sip
contact
was
location
until
we
figured
out
it
needed
to
be
named
at
her
form
and
location
was
just
at
her
spec,
so
we
renamed
it
so
I
mean
it
seems.
I
mean
I,
doubt
there's
very
much.
Pre
25:43
code
still
running
out
there.
E
They
can
use,
but
I
mean
it
just
I,
don't
know
I
mean,
would
existing
thing,
how
confused
with
existing
things,
be
getting
in
contact
in
a
401.
G
A
A
A
G
A
H
Going
okay,
so
this
is
something
called
seat.
Pusher,
please
go
to
the
next
slide
and
one
one
thing
I
want
to
make
clear
from
from
the
beginning
is
to
say
what
this
is
and
what
it's
not.
This
is
not
a
new
push
notification
mechanism
using
sip.
That's
not
what
this
is
about.
This
is
about
a
mechanism
for
transporting
push
notification
parameters
between
us
push
subscriber,
which
would
typically
be
a
cqa
and
that
push
notification
notifier
see
proxy
what
I
call
it
using
sip
for
usage
with
existing
push
notification
making
services.
H
For
example,
you
have
Apple
push
notification
APNs,
you
heard
firebase
cloud,
you
have
RFC,
80,
30,
based,
etc.
So
so
again
we're
not
defining
a
new
push
mechanism
here.
So
next
slide.
So
then,
what's
the
problem,
the
problem
is
that
previously,
when
you
made
boy
public
or
when
you
made
I,
oh
s,
applications
this
is
at
the
moment.
This
is
a
problem
in
iOS.
H
It's
that
there
was
a
mode
which
was
called
VoIP
mode
actually,
which
means
that
when
I,
when
applications
was
in
sleeping
mode
or
suspended
mode,
it
could
be
woken
up
when
there
was
a
network
message
in
the
SIP
case.
That
would
be
an
incoming
invite,
so
the
application
woke
up
processed
in
white
and
everything
was
fine,
knowing
latest
versions
of
iOS
that
has
been
removed.
H
Android
has
something
similar.
Currently
they
don't
mandate
the
usage
of
us
over
push
mechanism.
You
can
still
send
the
invite
to
the
Android
phone
and
the
application
we
will
wake
up,
whoever
they
do
recommend
usage
of
uber
push
also
in
order
to
to
to
wake
up
applications
or
who
knows,
sooner
or
later
they
may
actually
adopt
the
same
thing.
I
got
some
text
there,
there's
even
a
link
there,
where
you
can
see
the
official
note
from
Apple
I
try
this
link
five
minutes
ago,
and
it
actually
works
so
Nexus.
H
So
this
is
kind
of
background
why
this
is
needed.
So
so
next
slide
please.
So
this
is
basically
a
picture
showing
showing
the
thing
we
want
to
do.
You
have
to
subscribe
it
there,
which
is
in
our
case
again
a
CPU,
a
I,
think
the
red
text
or
the
red
arrows
here
are
actually
sip
messages:
the
blue,
the
blue
arrows
of
other
protocols,
which
which
are
also
discard
what
we
want
to
do
here
normally
they're
based
on
HTTP,
but
it
could
be
something
else.
So
you
have
your
application.
H
It
subscribe
to
up
notification
events
from
from
from
the
service
it
gets
back.
I
call
it
a
push
resource,
ID
prid
in
this
document,
because
I
want
to
make
a
generic
solutions.
If
you're
familiar
with
Apple,
for
example,
they
call
it
something
else,
firebase
calls
it
on
something
else
and
so
on,
but
but
I
thought
this
was
a
good
generic
term
as
I
we
say
later
when,
when
you
define
the
usage
for
a
specific
service,
you
will
actually
have
to
map
this
to
that
specific
service,
or
so
implementers
know
what
what
what
it
is
now.
H
The
idea
here
is
that
then,
when
you
get
this
and
when
you
send
your
register,
you're
actually
going
to
include
this
information
in
your
sip
register,
request
and
after
you've
done
that
at
some
points,
this
the
void
application
is
suspended
because
you
know
you
may
use
some
other
application
and
then
at
some
point,
there's
going
to
be
one
trigger.
This
could
be
or
a
typical
case
is.
This
is
a
sip
invite,
but
it
just
could
also
be,
for
example,
that
the
network's
requires
that
you
have
to
do
a
read
registration
or
something
like
that.
H
So
you
get
this
trigger
the
the
proxy
which
takes
care
of
this
gets
it.
It
sends
a
push.
Message
again
includes
the
spread
and
some
additional
information
which
is
service.
Specific.
The
push
notification
service
gets
these
forwards
to
the
CPU,
a
CPA
wakes
up,
and
then,
when
this
invite
is
forwarded,
it
will
be
able
to
receive
it
and-
and
you
know,
set
up
the
call
and
everything
like
that,
so
things
work,
but
if
you
wouldn't,
if
you
just
forward,
is
if
in
white
it
would
not,
the
UA
would
not
be
able
to
receive
it.
H
So
next
slide,
please.
This
is
the
same
thing
and
here
I'm
trying
to
gain
to
show
actually
what
what
scope
of
the
draft
is.
I.
It's
basically
distributing
these
these
parameters
to
to
to
the
to
the
proxy
or
the
publisher,
notifier,
that's
what
is
it
all
about
again
we're
not
touching
the
existing
services
or
in
the
push
services,
or
anything
like
that.
Krister.
H
H
Okay,
I
don't
have
that
since
lights,
but
but
you
have
to
remember
that
there
could
be
a
net
or
something
in
between.
So
you
need
to
send
this
registering
open
to
open
this
not
binding
again.
So
there
is,
there
is
actually
in
the
draft.
There
is
a
nut
consideration
section
which
talks
about
that.
So.
E
H
H
D
This
has
been
Campbell
up
here
as
an
individual
I
want
to
push
a
little
more
on
what
Brian
was
saying.
You
know
you
have
a
race
condition
right
now
between
the
trigger
and
the
push
message
and
the
fit
message
and
making
time
your
solution
doesn't
seem
like
a
general
solution,
and
it
also
occurs
to
me
that
this
is
almost
isomorphic
to
things
we've
done
before
when
it
comes
to
trying
to
identify,
with
some
token,
a
particular
way
to
get
to
the
user
agent.
D
It
feels
kind
of
like
outbound
and
some
of
those
things
we've
done
before
so
I.
Really
what
this
comes
down
as
a
scope
question
about
how
much
this
draft
needs
to
worry
about
how
you
know
when
the
client
is
ready
to
receive
the
triggering
thing
and
there's
this
transaction
timing
issues
there
to
write
a
particular.
If
it's
an
on
invite.
If
this
is
a
message
or
a
notify,
oh
yeah,
that's
me
or
something
again,
I
you.
H
H
Again,
as
far
as
I
understand,
this
goes
very
quickly
and
I
also
believe
that
in
some
cases
you
actually
there
is
actually
the
the
publisher
is
actually
going
to
get
a
message
back
when
when
the
message
has
been
delivered,
I
don't
know
if,
if
both
Appling
and
firebase
and
although
support
and
then
in
that
case,
you
could
of
course
wait
for
that
and
until
you,
you
forward
in
white
but
I,
don't
think
transaction
timers
or
things
like
that
is
gonna,
be
an
issue
because
this
this
actually
decide
happens
very
quickly.
So
so
so
what.
D
You
mean
by
very
quickly
when
you're
having
to
send
a
message
out
to
a
third
party
host.
It's
gonna
get
around
to
delivering
at
what
it
can
sorry.
So
writing!
So,
when
you're
you're,
sending
your
push
request
off
to
a
push
notification
server
that
you
don't
control,
it's
across,
probably
the
internet
and
it's
gonna
get
to
this
push
notification
when
it
can,
depending
on
how
busy
it
is.
What
do
we
mean
by
very
quick
I.
H
D
H
When
we
can't
guarantee-
but
it
says
I
mean
there
can
also
be
something-
can
always
go
wrong.
It's
the
same
thing,
even
in
cases
where
you,
where
you're
forwarding
right,
maybe
it
gets
lost
somewhere.
The
network
doesn't
work.
You're
always
gonna.
Have
that
case
where,
when
there
are
delays
in
the
network
and
I
mean
there,
of
course,
things
can
go
wrong
if
and.
D
When
we
talk
about
adopting
the
work
about
whether
or
not
how
much
work
this
draft
needs
to
do
on
solving
the
connectivity,
potential
connectivity
issues
and
I
can
see
it
saying:
oh
yes,
these
things
could
exist,
and
maybe
you
need
to
be
an
outbound
through
a
proxy
or
any
number
of
things
or
I
can
see
it
going
into
detail
with
normative
stuff
and
I
think
either
might
be
reasonable,
but
we
can't
even
know
what
we're
starting
up.
What
we
mean
to
do.
We
start
out
I
mean.
H
The
whole
idea,
of
course
this
is
for
the
community,
decide
I,
wouldn't
really
like
to
go
into
too
much
details
regarding
normally
what
the
U
has
to
do
and
those
kind
of
thing
this
is
this
is
about.
You
know,
waking
up
the
application
and
and
and
again
currently
I,
don't
even
suggest
to
include
in
this
push
message
why
it
has
to
be
it
could
be
a
reiteration
or
a
or
or
it
could
be,
a
invite.
H
If
someone
has
things,
there's
a
need
to
include
actually
what
why
this
comes,
they
can
do
it,
but
I,
don't
think
we
need
to
standardize
that
that's
just
gonna,
be
that's
gonna,
be
additional
information
that
you
know
you
can
send
PI
a
payload
in
in
this
push
message,
but
we
don't
specify
that
the
payload
you
have
to
include
there.
You
know
it's
its
application.
Specific
sorry.
C
H
I
will
know
anybody,
but
you
know
that's
a
very
good
point
and
isolation.
Something
which
is
in
a
draft
is
privacy
because
you're
not
going
to
send
any
user
information
or
SiC
private
I
mean
you
did.
The
only
thing
you're
going
to
send
up
to
the
push
notification
service
is
what
you
normally
would
send
up
when
you
do
your
your
registration,
you're,
not
gonna,
send
any
sip
identities
or
anything
like
that.
H
The
push
notification
service
may
not
even
know
that
this
is
worship,
it's
just
a
subscription
and
when
sometimes
some
someone
triggers
I'm
gonna
send
this
down
to
him.
Actually
there,
even
if
you're
concerned
about
the
payload
that
can
be
included
what
the
drafts
also-
and
this
was
requested
by
Martin
Thomson.
It's
actually
a
reference.
Is
this
Martin's
this
web
push
security
draft
which
allows
you
to
do
have
basically
end-to-end
encryption
of
the
payload?
It's
not
needed
for
this
mechanism
to
work,
but,
but
you
know
it
was
added,
thereby
by
his
request
and
I.
C
H
C
Significant
delay
between
the
invite
triggering
the
the
notification
departs
a
user
agent
and
the
user
agent
waking
up
and
being
ready.
So
this
can
take
some
time.
It
can
tell
that's
good,
but
I
mean
this
is
something
I
mean.
You
know
you
usability
test.
I
said
in
the
usability
lab,
the
user
was
instructed
to
install
the
application,
and
there
was
do
you
want
this
application
to
have
push
notification?
No.
H
I
Sean
Leonard,
so
I
don't
usually
participate
in
the
sip
stuff.
However,
as
a
recent,
pretty
intense
sip
end-user
I
guess
I
see
that
there's
a
lot
of
promise
for
the
strap
and
I
would
like
to
see
more.
That
I
actually
read
the
draft
and
I
didn't
see
where
it
discusses
the
problems
with
including
sip
payload
information
in
the
push
notification.
So
maybe
I
missed
it,
but
I
did
just
read
the
draft.
It's.
I
H
I
I
So
if
you
don't
trust
the
push
notification
services,
implementation
of
encryption
or
if
it's
not
satisfactory,
you
could
encrypt
those
messages
as
well,
and
one
of
the
other
features
of
using
SMI,
more
CMS
with
sip
messages
is
that
it
is
possible
to
compress
the
messages
as
well.
So
that
may
give
you
just
enough.
You
know,
margin
to
be
able
to
shove.
Sip
invites
into
a
push
notification
packet
to
compress
it
encrypt
it
and
then
send
it
along.
So
there's
there's
some
interesting.
H
Include
something
simony:
if
someone
wants
to
do
that,
but
I
don't
think
the
director,
because
I
like
I
said
I
think
there's
a
lot
of
problems,
for
example,
because
three
to
six
one
for
example,
says
that
the
response
should
be
sent
where
the
request
came
from
and
you
get
this
invite
from
Harry,
and
you
have
no
idea
I
mean
you
may
have
a
via
header,
but
you
know
it's
not
always
sure
data
and
I
mean
I'd
like
to
you
know.
If
someone
wants
to
do
that
as
an
implementation
issue,
I
don't
know
but
I
think.
H
As
far
as
the
draft
isn't
concerned,
you
are
at
least
going
to
forward
this.
Invite
using
sip
routing
make
an
instance.
We
don't
want
to
change,
sip
or
or
see
prowling,
because
that's
just
gonna
be
a
mess.
I
mean
that's.
That's
that's
one
of
the
reason
I'm
standing
here,
because
some
of
the
suggestions
I've
seen
their
priorities
suggest
and
do
those
kind
of
things
and-
and
they
have
very
specific
assumption
how
the
network
works.
There
are
no
proxies
in
between
and
so
on
and
so
on.
H
E
Point
being
that,
given
that
the
solution
of
Nats
and
firewalls
also
solves
the
race
condition,
I
maybe
put
build
that
in
you
know
you
have
to
have
something
like
outbound
in
there
period,
you
know
basically
so
that
the
invite
the
invite
is
sent
as
soon
as
effectively
you've
rear,
edge',
stirred
I
feel
like
that
solves
both
the
race
condition
and
that
and
firewall
problem.
So
maybe.
A
E
It
feels
like
encouraging
people
to
I
mean
then,
maybe
nobody
would
because
they
try
it
and
it
just
wouldn't
work
but
encouraging
people
to
write
something
that
a
has
a
race
condition
and
B
doesn't
work
behind
nuts
and
firewalls.
By
just
doing
the
simple
version
of
this
draft
is
you
know
not
a
modern,
useful,
no.
E
E
G
It
yeah
I
think
it's
a
it's
a
very
useful
draft,
but
I
still
AM
that
concern
with
with
a
delay
with
that,
in
this
case,
you're
talking
about
the
application
being
suspended.
In
some
cases
it
will
be
killed
completely
killed
and
you
have
to
really
launch
that
application.
So
so
it
is.
It
is
a
valid
concern
that
we
need
to
really
think
about
right.
D
H
You
can
always
see
it
forward,
they
they
invite
and
see
what
happens,
but
then
again
then
you're
gonna
delay
that
push
not
to
be
or
you
can
send
both
of
them
and
the
application
will
have
to
and
if
the
application,
when
it
gets
a
push
notification,
if
it's
already
up
and
it
has
to
receive
invite
I
mean
those
we
need
text
about
that.
But
I
can't
answer
you.
You
know
I
think.
H
A
H
Next
slide,
please
yeah,
oh
yeah,
so
this
is
just
you
know
what
this
draft
is
doing.
It
defines
new
CPI
parameters.
Are
there
being
some
comments
on
those,
so
I?
Don't
think
we
need
to
discuss
the
details
of
those,
but
this
is
what
it
does.
It
defines
one
year,
I
parameter
for
carrying
this
parade
value
and
underneath
the
one
parameter
for
Espeon
type,
which
this
P
and
type.
Actually
it
includes.
H
You
know,
watch
services,
this
Apple,
firebase
and
so
on,
and
then
some
service
specific
parameters,
because
some
services
they
have
in
addition
to
this,
they
have
some
extra
information
that
you
need
to
send.
But
this
is
service
specific
and
then
there
are
a
couple
of
our
headers
there,
which
can
be
used
by
this
draft
ITF
encryption.
In
order
to
provide
this
information
and
also
there's
a
new
I,
honest
operative
I
mean
we
want
to
make
this
as
a
generic
mechanism,
so
you
can
register
in
this
P
and
s
provider
values
at
the
moment.
H
This
is
only
an
issue
it
with
you
know,
with
mobile
terminal,
so
basically
we're
gonna
have
a
apple
and
firebase
and
and
those
are
actually
predefined.
In
the
draft,
but
we
still
want
to
make
it
generic
if
it
also
to
allow
for
other
other
services,
so
we
don't
have
to
write
a
new
draft,
so
yeah
I
on
a
registry
and
what
kind
of
information
you
have
to
do
for
that
and
the
next
slide
please
yeah.
This
is
just
an
example.
You
will
no
sleep,
so
I.
Don't
think
we
need
to
spend
time
on
this
one.
H
It's
the
next
one,
please,
okay,
so
who
needs
this,
and
and-
and
this
is
something
which
I
want
to
stress-
is
that
this
is
operators
need
a
solution.
Now,
as
we
speak,
I
mean
I
know
both
you
know
my
company
and
other
vendors
are
having
discussions
about
this
and
I
think
this
is
what
I
want
to
point
out
that
this
is
not
a
new
feature.
That's
put
in
a
roadmap
for
for
a
release
at
some
point
as
leases
I'm
concerned
or
what
I
know.
C
H
A
time
issue
there
there
ways
you
can
do
this
now
you
can,
you
can
use
the
older
versions
of
the
iOS
SDK
sand
and
think
you
can.
But
that's
I
mean
it's
it's
just
a
matter
of
time.
Some
of
the
operators
have
have
indicated
on
the
list.
There
are
also
other
operators
who,
unfortunately,
don't
don't
participate
in
ITF.
That
also
need
is,
like
I,
said,
have
a
while
ago,
there's
different
IDs
for
proprietary.
No
me,
probably
solutions
flowing
floating
around
I
mean
I've
seen.
H
So
of
course
everyone
comes
up
with
yourself,
but
the
message
I've
got
is
that
yes,
if
there
would
be
a
standard
solution,
we
can
use
that
because
everyone
realize
is
that
having
to
do
Wender,
specific
and
terminal
specific
in
the
in
the
long
run.
It's
not
it's.
Not
going
to
work,
it's
gonna
be
a
big
mess.
Did.
C
H
C
H
Those
are
all
good
comments
and
we
need
to
have
text
on
that,
but
I
mean
I
I
didn't
want
to
you
know
before
we
have
before
we
know.
If
there's
interest
you
work
on
this
so
next
slide.
Please
I
think
that
yeah
basically
so
so.
My
suggestion
is
that
that,
but
that
we
adopt
this
because
I
mean
like
I
said
this
is
needed
and,
and
it's
it's
needed
yesterday
or
or
even
earlier,
so
so
from
from
us
perspective.
H
A
Any
I
mean
this
has
had
a
lot
of
lists
discussion,
so
there
clearly
is
a
lot
of
interest
in
it.
So
I
think
chairs
are
inclined
to
ask
for
adoption
and
a
milestone
and
all
that
we
have
to
juggle
when
we're
doing
what
so
and
genes
not
here.
So
we
can't
you
know,
but
but
clearly
this
is
high.
I
mean
there's
been
a
lot
of
us.
This.