[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ecrit] Identifying the Appropriate PSAP section (<draft-schulzrinne-ecrit-requirements-01.txt>)
hi all,
please find my comments below (#).
this section seems to require some editing.
6. Identifying the Appropriate PSAP
# this section outlines the requirements for the mapping protocol.
# maybe we should just give it that name.
# i also think that the next few paragraphs can be replaced by a short
paragraph describing the problem statement.
# this is all about determining the mapping between location information
and one (or multiple) uris.
# it is ok to mention that there are two approaches for triggering the
mapping protocol:
* caller-based
* mediated.
From the previous section, we take the requirement of a single (or
small number of) emergency addresses which are independent of the
caller's location. However, since for reasons of robustness,
jurisdiction and local knowledge, PSAPs only serve a limited
geographic region, having the call reach the correct PSAP is crucial.
While a PSAP may be able to transfer an errant call, any such
transfer is likely to add tens of seconds to call setup latency and
is prone to errors.
# the last sentence either needs more explanation or needs to be
removed.
(In the United States, there are about 6,100
PSAPs.)
# what is the relationship to the rest of the paragraph?
There appears to be two basic architectures for translating an
emergency identifier into the correct PSAP emergency address. We
refer to these as caller-based and mediated. In caller-based
resolution, the caller's user agent consults a directory and
determines the correct PSAP based on its location.
We assume that
the user agent can determine its own location, either by knowing it
locally or asking some third party for it. A UA could conceivably
store a complete list of all PSAPs across the world, but that would
require frequent synchronization with a master database as PSAPs
merge or jurisdictional boundaries change.
# i would delete these few sentences. it is obvious that the entity that
triggered the mapping protocol needs to use location information as
input to the protocol.
For mediated resolution, a call signaling server, such as a SIP
(outbound) proxy or redirect server performs this function. Note
that the latter case includes the architecture where the call is
effectively routed to a copy of the database, rather than having some
non-SIP protocol query the database.
# what should the last sentence tell us?
# is this a protocol proposal?
Since servers may be used as
outbound proxy servers by clients that are not in the same geographic
area as the proxy server, any proxy server has to be able to
translate any caller location to the appropriate PSAP. (A traveler
may, for example, accidentally or intentionally configure its home
proxy server as its outbound proxy server, even while far away from
home.)
The resolution may take place well before the actual emergency call
is placed, or at the time of the call.
# we could add this somewhere to the requirements? if the resolution
took place before the emergency call was triggered then no constraints
are imposed on the solution. in fact this statement is captured with
I42.
The problem
# Location-based (or context based) routing
is harder than for traditional web or email services.
There, the originator knows which entity it wants to reach,
identified by the email address or HTTP URL.
# i think that the comparison with http is not really appropriate.
However, the emergency
caller only dialed an emergency identifier. Depending on the
location, any of several ten thousand PSAPs around the world could be
valid.
# we use several different terms to denote a psap that is responsible
for a certain geographical region: valid, appropriate, correct
In addition, the caller probably does not care which specific
PSAP answers the call, but rather that it be an accredited PSAP, e.g.
one run by the local government authorities. (Many PSAPs are run by
private entities. For example, universities and corporations with
large campuses often have their own emergency response centers.)
# i suggest to move these issues down to the requirements. the fact that
a psap might be run by a private entity is an operation requirement and
might not even belong to this document.
Schulzrinne & Marshall Expires November 2, 2005 [Page 13]
Internet-Draft ECRIT requirements May 2005
I1. Correct PSAP: Calls Must be routed to the PSAP responsible for
^^^^
# MUST
this particular geographic area.
Motivation: In particular, the location determination should not
be fooled by the location of IP telephony gateways or dial-in
lines into a corporate LAN (and dispatch emergency help to the
gateway or campus, rather than the caller), multi-site LANs and
similar arrangements.
# i don't see how the motivation relates to the requirement
I3. Multi-stage resolution:
# multi-stage resolution is a confusing term here. we should use terms
we introduced in the terminology section.
A mapping server for a large geographic
area SHOULD be able to refer clients to mapping servers
responsible for subsets of the geographic area.
# this requirement should read :
"The mapping protocol MUST support redirection functionality." (if we
use the terms 'mapping protocol' and 'redirection')
Motivation: In some cases, an initial mapping may provide a single
URL for a large geographic area. The ESRP identified by that URL
then re-invokes the mapping protocol on a different database to
obtain another URL for an ESRP or PSAP covering a smaller area.
I4. Return multiple PSAPs: The mapping protocol MUST be able to
return multiple URLs for different PSAPs that cover the same area.
The mapping protocol MUST provide additional information that
allows the querying entity to determine relevant properties of the
URL.
Motivation: In some cases, the same geographic area is served by
several PSAPs, for example, a corporate campus might be served by
both a corporate security department and the municipal PSAP. The
mapping protocol should then return URLs for both, with
information allowing the querying entity to choose one or the
other. The choice would typically be made by an ESRP based on
local policy, not by a human user.
# the last sentence does not make sense if you also support caller-based
resolution.
I7. Traceable resolution: The entity requesting mapping SHOULD be
able to definitively and securely
# what does 'definitively and securely' mean?
determine the entity or entities
who provided the emergency address resolution information.
# we should be a bit more specific about this requirement. what is the
impact of this requirement?
is it sufficient to add an attribute to the returned object that the
mapping was provided by X or do we demand signing of the entity that
created the mapping?
I8. Resilience against server failure: A client MUST be able to fail
over to another replica of the mapping server, so that a failure
of a server does not endanger the ability to perform the mapping.
I10. Incrementally deployable: The mapping function MUST be capable
of being deployed incrementally.
# here starts the motiviation.
It must not be necessary, for
example, to have a global street level database before deploying
the system. It is acceptable to have some misrouting of calls
when the database does not (yet) contain accurate boundary
information.
Schulzrinne & Marshall Expires November 2, 2005 [Page 14]
Internet-Draft ECRIT requirements May 2005
I13. Existing infrastructure support:
# this requirement needs to be split into a requirements part and a
motivation part.
It SHOULD be possible for the
mapping function to provide information that allows the requesting
entity to determine if ecrit compatible emergency call support is
available in the jurisdiction where the location is proferred for
mapping.
# hmm. i am not sure what this means.
Where ecrit compatible emergency calling is NOT
available, the mapping function MAY yield information which could
be used to route emergency calls using existing, country specific
methods.
# what is ecrit compatibility?
in the working group we develop requirements and (hopefully soon) a
solution for a mapping protocol.
For example, a tel URI may be provided for a PSTN routed
call, or a routing code which has meaning only within a country
specific routing mechanism.
I25. Mapping can be requested from anywhere: The mapping protocol
MUST be able to provide the mapping regardless of where the
querier is located, either geographically or by network location.
Motivation: The querier, such as the ESRP, may not necessarily be
anywhere close to the caller or the appropriate PSAP, but must
still be able to obtain a mapping.
I31: In response to a mapping request, a server will normally provide
a URI or set of URIs for contacting the appropriate PSAP. The
protocol must also be to return a URI or contact method explicitly
marked as an alternate contact. When this is used will be
described in an operational document.
# rewrite this paragraph as a requirement:
# I31: Multiple URIs: The mapping protocol MUST allow a response to
carry multiple URIs.
# the alternative contact might be a separate requirement.
I39: It SHOULD be possible to have updates of location (which may
occur when measuring devices provider early, but imprecise "first
fix" location) which can change routing of calls.
# add I39: Location Update:
I40. The mapping protocol MUST be extensible to allow for the
inclusion of new location fields.
Motivation: This is needed, for example, to accommodate future
extensions to location information that might be included in the
PIDF-LO.
# reference to pidf-lo missing.
I41. Split responsibility: The mapping protocol MUST allow that
within a single level of the civic address hierarchy, multiple
mapping servers handle subsets of the data elements.
# why is this only related to civic location info?
Motivation: For example, two directories for the same city or
county may handle different streets within that city or county.
I42. The mapping function MUST be able to be invoked at any time,
including while an emergency call is in process.
ciao
hannes
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit