1. Critical Issues Forum i3 – The future and beyond Brian Rosen Emergicom

2. Caveats for this session Lots of different stakeholders here – I’ll be moving back and forth among messages to each of them I’ll cover some things at a very high level initially, and later go into some more detail on them Some repetition of Henning and others’ points i3 isn’t agreed yet, this is my opinion of how things will turn out

3. Reminder of the basic Emergency Call problem Determine a call is an emergency call Route the call to the correct PSAP Include the location of the caller so help can be dispatched to the right place Include a way to call back if disconnected

4. The “Sierra Leone” problem Patron at a Starbucks café has a laptop with WiFi connection to the Internet VPN Tunnel exists to Patron’s employer Softclient on laptop connected to employer’s VoIP PBX An accident happens, and the patron dials 9- 1-1 for help

5. Sierra Leone cont. – So What? The Starbucks is in Chicago The employer is Sierra Leone Trading Intl Its VSP is Sierra Leone VoIP Services Pty Its ISP is Cable and Wireless Starbucks uses T-Mobile to supply the hotspot There are no contractual relationships except that between S.L. Trading and S.L. VoIP There is clearly no contractual, legal or other relationship between the Chicago PSAP and any entity in Sierra Leone

6. Assumptions for i3 PSAP is on the Internet (maybe behind a big firewall) Call taker answers VoIP call, not a gateway to existing technology Databases can change Database access mechanisms can change Not necessarily a carrier in the path Inherently multimedia: Voice, video, image, text,.. Addresses are not necessarily numbers (e.164)

7. Challenges for i3 PSAP is on the Internet (maybe behind a big firewall) Call taker answers VoIP call, not a gateway to existing technology Databases can change Database access mechanisms can change Not necessarily a carrier in the path Inherently multimedia: Voice, video, image, text,.. Addresses are not necessarily numbers (e.164)

8. PSAP is on the Internet This means that anyone can place a 9-1-1 call to the PSAP Must deal with viruses, Denial of Service attack, etc. directed to the PSAP Need to have the routing database publicly available to all

9. Call taker answers VoIP Implies that the design of the PSAP changes from a TDM switch (SR + PBX) to a data network Must make VoIP protocol choices

10. Databases can change More information can be provided Data can be reorganized to better fit the source and use of the data Need to figure out how to populate and maintain the data accurately

11. Data Access Mechanisms can change New, IP based protocols will be used to access the data These protocols are, for the most part, promulgated by the IETF, a new partner for the 9-1-1 community Data will be public, raising security and privacy concerns

12. Not necessarily a carrier Anyone can set up a VoIP system Large enterprises/organizations probably will, much as they run their own email system Means that you cannot rely on a carrier to do data management and validation Means that you cannot rely on a carrier to deal with problems

13. Inherently Multimedia Will support video, images and text (Instant Messaging) from the start Means that the “phone” at the call taker workstation is NOT a simple VoIP set Work towards passing this media towards the responder Implies recording systems change

14. i3: It’s bigger than just us The U.S. (or even North America) can’t design their own system – The Sierra Leone Problem – Roamers from, say, Japan – Purchases by local citizens of equipment from other countries There are NO national variants of any Internet protocol The solution is to make the solution an international solution, primarily promulgated in the IETF NENA can have significant influence in this process

15. How this will work (at least at i3) The phone learns its location from the LOCAL environment – DHCP supplies location when the laptop gets it’s IP address – This is the right location, before the VPN tunnel is established Location is carried in the signaling, with the call There is an available routing database so that anyone, worldwide, can route the call to the correct PSAP

16. This will be a significant change to the PSAP It’s not really possible to gateway VoIP calls to existing systems, we will gateway PSTN calls to VoIP Not limited to voice Much more data associated with the call Much more routing flexibility that existing systems, especially in the Selective Router, can supply And one more thing

17. The Current 9-1-1 system is dangerously vulnerable to deliberate attack Current congestion control mechanisms limit the number of calls into the PSAP to a very small number Current Internet Viruses can infect 10s of thousands of machines, more than 50% of which have modems connected to existing PSTN lines If a virus was directed to call 9-1-1, wait for answer, hang up and try again from thousands of machines spread out all over the country, the entire 9-1-1 system would be taken down. Not related to VoIP. Such a virus has ALREADY been written, but not widely deployed There is no defense available to stop this kind of attack

18. Routing is non trivial, especially in North America There are approximately 6,134 PSAPs in North America Each has a service boundary They are NOT necessarily aligned to any political (state/county/city) boundary Call must be routed to the correct PSAP There are databases that exist for civic and geo locations that tell you where to route the calls But currently, access to them is restricted, and has cost associated with it Other areas are easier (one PSAP for a country) others are harder (no existing database)

19. Location In Enterprises Getting to the right “address” is not enough – Think of this as the “yelling” test All enterprises who have large facilities will need to provide more specific location information We’re going to make this as easy as possible, but it’s still going to be some level of burden on enterprise

20. Making Location work in Enterprise VoIP Same basic idea – phone learns location from its local environment – Could be proprietary to your VoIP vendor – Standards based approaches are feasible now – RFC3046 describes a mechanism to determine the switch port a packet arrived on – Or check out LLDP-MED This gives you the basis to use a (manually maintained) wiremap database (room number to switch port) to determine location – and that is where the cost is DHCP can be used to supply this location to phones Location to building/suite/floor/room can be specified

21. Location for Residential VoIP Voice Service Providers don’t have much of a role because they don’t know where the customer is AND THEY DON’T HAVE A RELATIONSHIP WITH ANYONE WHO DOES The ISP may or may not know, but if they don’t they have a relationship with someone who does The Access Infrastructure Provider knows where the customer is

22. Access Infrastructure Providers “First Mile” infrastructure owner, wireline or wireless Wireline AIPs already have a notion of a Service Address, and a wiremap (or equivalent) database I believe ALL AIPs, regardless of technology, and regardless of whether they offer voice/video/text services, must supply location It’s likely that regulation will be required, and it’s likely to happen Fixed wireless (e.g. WiMax) vendors; plan on GPS receivers or triangulation mechanisms You heard it here first

23. ISPs If you are the AIP, you supply location to endpoints If you aren’t, contract with the AIP to get it If there is a system spec on all infrastructure including all end points, you can use any mechanism you like to get location to the endpoint If you don’t have such control, support at least DHCP

24. Cascaded Location Applicable to things like WiFi “AP” gets location from its environment, and relays it to its endpoints If possible, supply more specific location – The “yell test” again Works for things like café hotspots

25. Next Up - SIP Phone Vendors You have to get location from the environment as described If you do digit analysis in the phone, you have to learn the local emergency call number for the environment the phone is in – We are working on standards for this When you detect an emergency call, or the downstream proxy tells you its an emergency call, you must supply location

26. SIP Phone Vendors, cont. Because location is sensitive, IETF standards REQUIRE sips (TLS) for emergency calls PLEASE implement this now, pretty please Supply a good callback in Contact – Good as in, “reachable from the PSAP” Implement blind and supervised transfer (REFER/Replaces) 3 rd Party Call Control (for conferencing)

27. SIP Proxy Vendors – Your turn For i3, you need to implement routing based on location – This is the charter of the new IETF ECRIT working group – A DNS based approach will work, others may or may not, we’ll see You have to implement TLS too Allow callback from the PSAP – Probably more a configuration thing

28. What if you don’t support SIP? The standard interface to PSAPs, at least in North America, will be SIP Other vendors will have to gateway to SIP to send emergency calls Most vendors already support SIP, because most inter-enterprise/inter-carrier peering is SIP Must include location, as per SIP standards on the call

29. VSP Responsibilities Deploy TLS – So, beat up your (SBC) vendors. It’s the Right Thing To Do For i3, simple routing decision – Look up location in a database (DNS for example) – Forward call to where it says to – No 3 rd parties – Some proposals have the lookup occurring prior to placing a call, I think that won’t work but we’ll see Allow callbacks to Contact header May need identity assertions

30. Other communications service providers have a role too Video telephony/conferencing vendors, i3 PSAPs will take the calls – Also applies to camera phones IM vendors, i3 PSAPs will take the calls And for everyone, there will be a new generation of “TDD” devices based on SIP and interactive text streams. Please plan on supporting them

31. i3 Status “Long Term Definition” working group in NENA VoIP/Packet Technical Committee – Currently writing requirements – Will finish as early in CY2005 as I can push them IETF ECRIT Working Group – Probably will be chartered within a month – Specifically limited to routing calls – VoIP allows international roaming, and effectively international addresses (TNs/URIs) – Need a single global standard – There are NO national variants of IETF (Internet) protocols

32. Other information that comes WITH THE CALL Caller languages – automatically route to PSAP or call taker that speaks French – Accept-Language: fr Caller media preferences – automatically route to PSAP or call taker that can deal with typed text – Accept-Contact: *;text;require

33. Location Really, there are only two ways to determine location Measure it (e.g. GPS) Type it in (street address) – Hopefully, a carrier (or enterprise) function – If you started with a civic (street address) don’t translate Or we have to worry about what database you used to translate – PSAPs might have good databases But the general case is there will be errors in conversion Always send the original data We can handle multiple forms, if you have both, send them

34. Getting location on wired phones “DHCP” = protocol to get local infrastructure information Commonly used to assign the IP address to a device Now has a way to report location The entity that assigns (the first) IP address knows where the wire is

35. Routing a call to the right PSAP Many entities will route – Not necessarily a carrier, remember? – Carrier may not be local (Sierra Leone) Need a globally accessible routing database – Which returns the “URI” of the PSAP (like a phone number) – But in VoIP, we can “Authenticate” a caller – Which means we only accept “9-1-1” calls

36. The routing database Must be able to route civic and geo locations Must be able to be local, regional, national in scope, with exceptions – E.G. All calls to State of Florida go to sos@psap.fl.ussos@psap.fl.us – Except Dade county, which goes to sos@psap.dade.fl.ussos@psap.dade.fl.us Must be readable by anyone, but writable only by the PSAP/9-1-1 authority – Readers must be confident data is authentic and has not been modified

37. Proposal (not yet agreed) Use the “Domain Name System” Normally used to translate a domain name (like www.yahoo.com) to an IP address (like 123.112.62.10) www.yahoo.com The DNS is – Distributed – Hierarchical – Redundant – Reliable – And (with DNSSEC), secure

38. What do you mean Hierarchical? Multiple levels – Top level domain (like.com) – Second level domain (like yahoo) – N-level domain (geezer.pitt.comms.marconi.com) For 9-1-1 we will use sos.arpa – 123.main.pittsburgh.allegheny.pa.us.sos.arpa contains the URL of the PSAP that serves 123 Main Street – 235.5.newco.123.main.pittsburgh.allegheny.pa.us.sos.arpa would be the location reported for room 235 on the 5 th floor of the Newco suite at 123 Main St.

39. DNS is reliable Multiple copies of the “authoritative” data geographically distributed – E.G. St. Louis could have copies of Pittsburgh’s entries in the DNS DNS servers “cache” copies of the data Caches can supply data even if connections to authoritative servers are down DNS has not hard failed in last 15 years

40. DNS is distributed Domains are “delegated” by higher level domain (e.g. Commonwealth of Pennsylvania delegates allegheny.pa.us.sos.arpa to Allegheny county, only Allegheny county can put data in that domain Allegheny County has multiple copies of allegheny.pa.us.sos.arpa, PA has multiple copies of pa.us.sos.arpa, and they are in different servers Building Owners and Tenants can be delegated their entries and supply data themselves, or contract with someone else to do it DNS servers cache data locally = lots of copies all over the world Data has a lifetime (i.e. cached data times out and must be prefetched from authoritative source)

41. DNS is secure Cryptographic technology to assure – Only the authoritative server created the data – No “man in the middle” – No modification to the data Provides the basis to assure callers they reach the real PSAP when they call 9-1-1

42. PSAPs on the Internet – No Way! Way – The calls are on the Internet, so in some way, the PSAP is on the Internet – Yes, it may be that many calls come from a carrier over a private net – But many calls will really come over the “big I” Internet But that does not mean each PSAP is directly on the Internet Emergency Services Networks behind large firewalls – Might be state level, or more likely, city/county level interconnected up to state level – All public safety networks would be connected to these ESNs – But put a firewall between the ESN and your PSAP, please

43. Please don’t say “trusted” Never trust Always verify Use cryptography – Authenticate – Integrity Protect – Privacy Protect You want the data that is out there anyway Allow access, but protect against intruders Requires – Skills (not usually found in local IT groups) – Lots of bandwidth (gigabits) from the Internet

44. Response to Denial of Service Attack Unlike the current system, the i3 PSAP will have reasonable defenses for DoS attacks Signaling channels will handle 10s of thousands of calls Firewalls will filter out bad calls “Leakers” will be directed to any available call takers, and will only happen once per infected machine Firewall mechanisms will be flexible, and capable of being dynamically modified PSAPs will be on managed networks not directly accessible from the Internet

45. Legacy infrastructure Sure, wireline/wireless PSTN will be the majority of the calls for a while – Latest forecasts show 40% of wireline calls in U.S. will be VoIP within 5 years Gateway PSTN into VoIP PSAP – We’ll start with a gateway from S/R to the PSAP – But VoIP will have many new functions S/Rs can’t do – So expect to gateway CO to PSAP, eliminating the S/R eventually This might take a while DNS can tell you if PSAP is i3 upgraded!

46. Get ready: there is no ALI in i3 Location comes with the call We can dynamically query the MSAG equivalent as the call arrives for ESN and other data associated with the location This means we don’t need the ALI And we can get rid of all the processes to maintain it We’ll keep a simple form of it for PSTN

47. There is no ESN We have to build a mechanism to define the service boundary of a PSAP for both civic and geo We can use the same mechanism to define the service boundaries of any number of responders We don’t need codes A query to the new MSAG will return the URI (address & ELT equivalent) of the responders for the location

48. Eventually, there is no Selective Router The S/R is the root of the existing deliberate attack mechanism The S/R cannot transfer calls outside of the PSTN The S/R cannot handle non voice media streams The S/R cannot break the phone number/location mapping problem So, we’ll phase it out

49. Phasing out the S/R i3 will start with only VoIP calls coming in direct to the PSAP via IP We will deploy a gateway between the S/R and the PSAP to convert PSTN and wireless calls to VoIP. It will use the existing ALI Wireless can convert to VoIP at any time (no MPC required, just put location in the VoIP signaling) Then we will move the gateway to be positioned between the C5 and the PSAP, bypassing the S/R Eventually, I hope the PSTN carriers will deploy their own simple phone number to location mapping, and then we can decommission the ALI

50. Routing Flexibility in i3 We will have much more flexibility to route calls – Within the PSAP By media type (TDD), language preference, location – Between PSAPs Transfer to any i3 PSAP or responder WITH ALL DATA INCLUDING LOCATION Failure routes can be to any PSAP willing to accept the calls Route changes can be made dynamically, by PSAP management

51. i3 will lead to much more flexibility in disaster routing Let’s talk about congestion control No one deserves a busy Busy is the networks response to no resources available to help, usually, no call takers Callers get 1 bit of information from a busy – no one will help you, you are on your own PSAPs get no information from a busy; you don’t even know that it occurred Responders might be maxed out too, but they want to triage. First come first served is NOT appropriate And you can’t triage if you don’t get all the data

52. Disaster Routing in i3 We can, if we want to, route calls to any i3 PSAP anywhere in the country There are about 20,000+ trained call takers on duty at any one shift We can build databases that any PSAP can access and add data to (who, where what, how bad, …) We can provide instructions to callers We can, in some circumstances, provide first aid instructions

53. Why would we do this Major system failure Widespread disaster which overwhelms all regional facilities Deliberate attack which tricks existing firewall techniques until custom filters can be developed and deployed (maybe hours or a day)

54. We would only do it when both sides agree Sending PSAP has to enable offload Receiving PSAP(s) has to accept offload One or more groups will have to develop criteria and response plans so call takers can be trained It’s a disaster, we don’t need to use the same criteria and responses we would under normal circumstances

55. Lots of data will be available We can create data that is associated with a location Yes, you could put it in the GIS, but it makes more sense to actually construct a distributed database that ties all information we have about a structure We can delegate parts of this to building owners, if they are willing The structure data can be made available to responders as well as call takers and dispatchers

56. Data on callers VoIP has a notion of a user, distinct from the device (phone) We can create an (opt-in!) database of information about a caller – Medical data – In an emergency, contact,… Callers can roam, and the data comes with them

57. PSAPs will look a lot different Not much of current PSAP systems will survive There is no switch (S/R, PBX,..), it’s all in the data network Things like loggers will change (video, text, new data) You’ll still have a call taker workstation, CAD and radio console, but completely new code/functions/data organization Some operational differences, but mostly new capabilities; call answering isn’t going to change radically

58. Funding You can’t get a surcharge on CSPs, because they are not local and there may not even be one What you can do is to have a surcharge on the Access Infrastructure Provider Doesn’t matter if they aren’t the CSP, their facilities are used to place 9-1-1 calls Would apply uniformly to all AIPs, which includes existing facilities based wireline and wireless vendors, even cable companies They are always local, and always subject to regulation Also no ALI, and the MSAG has to be free, so the surcharge is all you get.

59. Funding, Access Infrastructure Provider burden and reimbursement This proposal loads the AIP with new responsibilities – Providing Location – Collecting and remitting surcharge With those responsibilities, there are costs There is precedent (wireless) to allow cost recovery from surcharge revenue This may make the scheme more palatable to the AIPs

60. Summary Phone Vendors – you have work to do Proxy Server vendors – you have work to do SBC vendors – you have work to do Access Infrastructure providers – you have work to do Internet Service Providers – you have work to do Communications Service Providers – you have work to do Enterprises – you have work to do PSAP CPE vendors – you have work to do PSAPs – your life will change, and you have work to do