|
|
Hi Martin,
Dawson, Martin wrote:
Hi Hannes,
Well... I can imagine a proxy in a residential LAN that knows how to
talk HELD to the access provider network when the client device (e.g.
legacy ATA) does not know how to. So the proxy does the request on
behalf of the ATA and does the insertion on the outbound.
\
I can imagine many scenarios as well
The problem with all these things is that
* we haven't described them clearly
* there are a number of options
* the client does not know in which environment it is in order get
things to work.
I can imagine an Asterisk server in an enterprise that knows how to talk
to the enterprise LIS and requests and inserts location on behalf of the
standard phone form factor IP handsets that don't know how to do it
themselves.
I know that these things are possible and this would be very similar to
the 3GPP emergency architecture where the user is actually at home.
In both cases, the option exists to route the call directly to whatever
URI the LoST service indicates is appropriate without any external VSP
being involved.
The VSP in this case would be the enterprise.
Or are you saying that these proxies are the "VSP" in these scenarios?
It's just a question of semantics?
Ciao
Hannes
Cheers,
Martin
-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@xxxxxxx]
Sent: Sunday, 15 July 2007 11:49 PM
To: Brian Rosen
Cc: 'ECRIT'
Subject: Re: [Ecrit] Phone BCP Draft Comments
Hi Brian,
sure that's fine. But the problem is the following: What proxy should
add location information other than a proxy in the access network.
So far, such a proxy does not exist in our emergency services
architecture. Right?
Ciao
Hannes
Brian Rosen wrote:
Hannes
I believe your opinion runs counter to consensus, and I'll bring this
up for
a hum at the meeting. I think most of us think endpoint insertion of
location is preferred, but proxy insertion, under the right
circumstances,
is acceptable.
Brian
-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@xxxxxxx]
Sent: Sunday, July 15, 2007 4:11 AM
To: Brian Rosen
Cc: 'ECRIT'
Subject: Re: [Ecrit] Phone BCP Draft Comments
Hi Brian,
Brian Rosen wrote:
The text now says that the phone applies normal outbound processing.
That
would mean it sends calls to the VSP. That's what we want.
Marc's phone would normally send calls to his house proxy. That is
what
we
want.
Typically, it would be the proxy of Marc's VoIP provider.
Let us try my way with the organization and see if it accomplishes
what
you
want. If it's a mess, I'll look at doing it your way.
I'll make sure we discuss proxy insertion of location in both
-framework
and
-phonebcp. I think it is best to state it is acceptable if the
limitations
implied (VSP has a relationship with ISP, has a good identifier that
ISP
can
use) hold.
I don't think we have a place in our current architecture for the
proxy
insertion for location.
We should first discuss that aspect from an architectural point of
view.
Ciao
Hannes
Brian
-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@xxxxxxx]
Sent: Saturday, July 14, 2007 5:38 PM
To: Brian Rosen
Cc: 'ECRIT'
Subject: Re: [Ecrit] Phone BCP Draft Comments
Hi Brian,
thanks for the quick response. Please see my comments below:
Brian Rosen wrote:
See in line
-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@xxxxxxx]
Sent: Friday, July 13, 2007 5:11 PM
To: ECRIT
Subject: [Ecrit] Phone BCP Draft Comments
Hi Brian,
Hi James,
Hi all,
I like the document, as I expressed several times in the past.
There are, however, a few issues with it.
Henning and myself have recently written an ECRIT overview
document.
See
http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture-
overview-00.txt
One thing that was quite important for us to highlight was that
the
IETF
emergency service architecture has a very nice property, namely
the
fact
that different VoIP protocols may be supported between the end
host
and
the VoIP provider. There is no need to implement SIP only.
Now, this document does not give me the impression that this
aspect
is
given enough consideration.
There are two things that came to mind when I read this. One is
that
you
are right, and we can be more clear that any protocol can be used
between
the endpoint and some kind of gateway that interworks to a
protocol
that
the
PSAP implements.
The other is that SIP need not be the only protocol the PSAP
implements.
That's certainly true. We do, however, have to start somewhere. We
cannot describe what Skype protocol features a PSAP has to
implement
for
an emergency service scenario.
Hence, we focus only on SIP. That's already enough for a PSAP to
implement.
We do, however, only mandate functionality that is absolutely
necessary
for interoperability.
However. There are some requirements on what the protocol needs to
do.
We
should list them, and I think probably that discussion belongs in
-framework. LoST already can return multiple URIs with different
schemes
corresponding to what it implements.
It might be a good idea to state what protocols have to support --
there
aren't too many things anyway.
The IETF emergency service architecture realistically requires
that
the
emergency calls are routed through the VSP in order to get
identity
information attached to an emergency call.
NO!!!!
That is NOT true. The PSAPs I work with will take calls that
don't
come
>from a VSP over the internet.
I guess you need to describe in more detail what you have seen.
They may well have some suspicion on such
calls due to the lack of a verifiable identity but they will take
the
call
anyway. I've had numerous conversations with PSAP people who want
to
make
sure I understand the "rules" they have (validated location for
examples).
When I press them for what they want to do when something goes
wrong
and
it
doesn't happen (like, validation fails, do they want unvalidated
location or
no location), they ALWAYS want the call, and they want the data
you
have.
They may treat the call with suspiscion. They may go back later
and
try
to
figure out why they didn't get what they wanted but they take the
call
and
ask questions later.
So please don't make that assumption. Ysa, we expect nearly all
calls
to go
through a VSP, but the system works if Marc Linsner's proxy in his
house
sends the call to the PSAP.
That's fine. It is just the question what we write into the
document.
What is the default behavior?
We sent the calls directly to the PSAP or via the VSP?
This has impact for the phone BCP document. If you assume that
calls
are
routed through the VSP then the protocol run by the end point does
not
matter too much.
If you assume that the end host MUST be able to route directly to
the
PSAP as well then you have to mandate a certain functionality at
the
end
point.
So, what behavior do we want?
Having said all that I believe that one important aspect, which
is
also
different to architecturs investigated by other SDOs, is that the
PSAP
has to support a certain functionality. This functionality is
described
in the document but might not be too visible to the working group
or
at
least hasn't be advertised a lot.
Yes, this is true. We could make that more explicit.
I believe we have to indicate quite close what the different
entities
have to support rather than meshing everything together. This
impacts
the document structure a bit.
Yes, we have thought about that a lot, and have had some
suggestions
in
that
the direction, the goal being to have all the BCPs for phones in
one
place,
those for the access network in another place, etc.
It's OK to have the required functionality listed in one document
even
though they address all the involved parties in the architecture.
Here is a suggested structure for the document:
* Introduction
Shorten the introduction
It contains a lot of info that is already available in the
framework.
This document has to be read in the context of the architecture
anyway.
We will do that
Btw, the introduction must not use RFC 2119 language.
Yes
* Terminology
Classical RFC boilerplate and pointers to the requirements
document.
* End Host Profile
This section just describes what is absolutely necessary for an
end
point to support the
This is essentially the location part, the LoST part.
This would essentially be Section 4.2, 4.3, 4.4, and 4.5.
The LoST stuff can be found in Section 6.3.
* ISP Profile
This is the location part. The server side of Section 4.2.
Optionally, LoST may be provided by the ISP.
You see where the problem is? You have the location part in both
End
Host
and ISP. Same with LoST.
This is the problem with this suggestion. It actually makes as
much
sense
to keep all the location information together as it does to keep
all
the
end
host information together.
My best idea to address this is to leave the structure as is, but
to
make
the BCP elements pulled out and labeled as to whom they apply
(endpoint,
VSP, ISP, PSAP). Then, after the functional sections, we can copy
the
BCP
elements (only, not the other text) and sort them by who they
apply
to.
It's not a big problem to consider location aspects at the ISP and
at
the end host since the demanded functionality is, to some extend,
different.
In this particular document we, for example, say that the ISP has
to
implement one of the location protocols and the client implements
all
of
them.
* VSP Profile
Some parts from Section 5 and Section 6 could go in here. Might
want
to
separate this into a separate sub-section to have a way to
reference
it
from the "End Host Profile" section to say something like
"When the end host implements SIP then the VSP might want to use
the
same functionality already at the client."
The detailed considerations about SIP location conveyance are not
necessary since they can already be found in the SIP Location
Conveyance
document already.
Actually, I think a lot of this text has to stay as it describes
how
you
use
the -conveyance mechanism. We'll take a sharp look at it for
deletions.
Section 6.2 does not work with the general IETF emergency
architecture,
as described in the ECRIT framework document. For example, the
proxy
does not obtain location information since it cannot do so in the
generic case.
I don't want IETF to be in the position of not supporting proxy
insertion of
location as, for example, 3GPP does. I think we explicitly allow
it
but
explain the difficulties.
The problem is that it does not work together with the framework
document.
The framework document does not have a case for it.
It's fine that the SIP Location Conveyance document has something
in
there that could potentially be useful for the 3GPP. The
interesting
case, however, is that the emergency services architecture of the
3GPP
has the functionality of the P-CSCF and the E-CSCF in the local
network
and hence they don't standardize the interaction with the PSAP,
unlike
we do because the PSAP in the IETF emergency services architecture
might
get the call from an arbitrary entity rather than from the local
network
operator.
Section 8 is also relevant.
* PSAP Profile
Section 6.5 is relevant but only to the extend where the PSAP
operator
network faces the outside world. I don't think it is too relevant
for
this document to talk about PSAP network interal operator, such
as
transferring a call to another PSAP operator.
Probably right, but the endpoint requirements to support transfer
must
stay
That's fine
Section 8 is also relevant.
* Security Considerations
Don't go too much into the details since we talk about all the
stuff
in
other docs.
If you say so. I'm not sure we can get away with this. Can we
ask
you
to
get a security reviewer assigned sooner rather than later and we
can
work
with him to see what we can accomplish with just references to
other
docs?
Good idea. We should do that.
The testing section is fine.
Albeit it mixes endpoint and PSAP BCP statements.
-- I am not so sure about the location update section.
There is nothing to reference. It has to be somewhere else, and
referenced
here, or here. This is a use of presence (and presumably HELD).
Hmm. I have to re-read that part.
In any case: Try to make the document as short as possible.
Okay
Thanks for the suggestions
Ciao
Hannes
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|