draft-rosen-nena-ecrit-requirements Brian Rosen NENA Requirements draft-rosen-nena-ecrit-requirements Brian Rosen

NENA North American (US/CA) Emergency Number Association VoIP/Packet Technical Committee Long Term Definition Working Group These requirements are a subset of the requirements of the LTD WG “i3” = Emergency Services system changes to accommodate IP

Basic North American Problem 6,134 PSAPs with some irregular boundaries Well developed civic and geo routing system All civic addresses are validated against the Master Street Address Guide Current system has good accountability for every entity along the signaling path

Signaling Need to know what happened – what elements were in the path, what they did Need to have internationally useable method for determining an emergency call, but must be able to use 9-1-1 in North America Must be able to gateway calls from PSTN in and have it work Need a way to have calls go to an e.164 for those areas not served by 9-1-1. Need Congestion Controls Everywhere

Location Location comes with the call, geo (x/y/z) or civic Issues of multiple locations reported in the call – need to specify how to handle it Separation of location provider from communication service provider Need defaults for routing when missing or incomplete location is reported Need a way to get location updates

Additional Information Need a way to associate additional info about the location Need to reflect domain hierarchy = building, tenant, … A URI in the database is enough Need a way to associate additional info about the caller Possibly distinguish between AoR and actual person

Validation You validate BEFORE you call Valid = address is in the master database In North America, we have multiple validation databases with irregular service boundaries (like PSAPs, and often coincident with a set of PSAP boundaries) The Postal vs Actual Community Name problem

Routing Calls must be routed to the correct PSAP based on the location of caller and declared boundary of the PSAP Routing must be possible on civic or geo Cannot REQUIRE conversion (geo <> civic), but should allow it PSAPs need control over routing & conversion data PSAPs declare their boundaries Some areas will have coarse boundaries (country/state). Others will have very irregular boundaries (river, all of a city minus 2 streets, …) Routing data has to be available to a large number of routing entities

Routing (2) Routing data must be secure (authentication, integrity protection) Routing data must be reliable, even in the face of disasters Need a way to have alternate routes, including some with e.164s Initial location may be inaccurate, requiring a re-route later on

Others Need a reliable call back mechanism Some need a “no hang-up” mechanism Need lots of redundancy to deal with failures of all sorts (not just routing data) Need a test mechanism Need mechanisms to distribute route failure information, and similar diagnostic data

What to do with this draft Make it the basis of the ECRIT requirements document OR Create a “design team” from authors of this and the other requirements drafts and charge them with coming up with one ECRIT requirements draft