|
|
But we cannot leave this aspect open. We need to specify actions that
the different parties have todo.
As part of this description, the framework document makes it very clear
that the end host obtains location information (*).
The 3GPP has a different architecture for emergency services and that's
fine.
We cannot just make such a vague statement that the VSP may add a
reference to location information without explain the big picture.
Ciao
Hannes
(*) In this discussion we ignoring the location hiding aspect for a moment.
Brian Rosen wrote:
That is up to the VSP. In the 3GPP case, they send emergency calls to the
E-CSCF. Others may do it on the first hop outbound (what would be the
P-CSCF). I don't think we care, and I don't think we even discuss it.
Brian
-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@xxxxxxx]
Sent: Sunday, July 15, 2007 9:49 AM
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
|
|