Subject: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 - Alternate Routes

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Oct 2005 14:58:17 -0400

More comments from NENA:

In our requirement 3.4-4, we said, Mechanisms must be provided to route
emergency calls in areas not served by E9-1-1 to an appropriate PSTN
telephone number.  I31 is related to this, but doesn't cover it adequately
we feel.  One way to improve it would be to use a tel uri with an e.164 as
an example. 

The issue of "default routing" must be covered in the requirements.  This
occurs when less than complete information or inconsistent information is
provided (for example, good community name, but bad street name).  In these
cases, some entity must determine a route.  In general, there is a "default"
route for levels of the address hierarchy when data below that level is
missing or inaccurate.  Generally, this is a "longest prefix match" problem.
The mapping function could do this itself, or it could accept a less than
complete query (no data below city name for example), and return a mapping,
pushing the error resolution process back to the entity requesting mapping.
We would prefer that the mapping function return a valid default mapping if
partial data is provided or data is inconsistent.  There are similar
mechanisms needed for geo routing.  As a separate requirement, it is
important that somehow, the destination know that default routing was used.
This implies that the mapping result includes some kind of flag that default
routing was used, and that flag can be propagated downstream.

Requirement I31b: The mapping protocol MUST be able to return a URI or
contact method explicitly marked as an alternate contact does not adequately
address our requirement 3.6-19: Multiple types of failures may have
different contingency routes.

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit