1. draft-rosen-ecrit-emergency- framework-00 Brian Rosen NeuStar CPa-060006

2. Purpose “Big Picture overview of how emergency calling on the Internet works Pointers to relevant documents Listing of specific options/combinations of existing specs that need to be used Should not be duplicative of other specs

3. General Emergency Call Flow Endpoints get location from access network Local Emergency Call Dial String is detected Call is placed with location and universal emergency URN in signaling Routing uses LoST to get URI of PSAP from service+location Normal (SIP/XMPP/…) routing procedures used to route call to PSAP

4. Location Basic IETF approach is to have access network supply location to endpoints –Endpoint is client of both access network and Communications Service Provider (Voice, IM, Video) network, which may not be the same entity –Eliminates need to force access network to have relationships with all communications service providers and vice versa Short list of protocols (in –phonebcp) –All phones implement all protocols –Access network implements at least one If access network and CSP are the same entity (or relationships exist), network can assert location on signaling Location can be geo or civic Only one location can be used for route (sent via LoST) Location carried in SIP via Location Header –by-reference or –by-value Civic location must be validated (via LoST) before use

5. Emergency Call Detection and Marking Local dialstrings depend on knowing where “local” is = location of caller LoST provides the dialstrings for a location Phone or network can do mapping to recognize emergency call Service URN (urn:service:sos) used to denote an emergency call Other markings will be required (to know it’s an emergency call once LoST has been used to route)

6. Call-Back & Other Information Must include Contact (for immediate call to same device) Must include AoR (for later additional information) Can include URI for additional info on caller –opaque URI –opt-in –could be carrier independent) Can include URI for additional info on call –Includes carrier ID and contact info –“Class of service” –Reference info carrier needs to assist PSAP

7. Testing Provide full test of signaling and media path for emergency call without PSAP human intervention Signaled by “test” URN parameter Routes just like emergency call Includes media offer/answer Auto-answer at PSAP Media loopback Will be limited use, and may not be available/enabled at every PSAP

8. draft-rosen-ecrit-phonebcp-01

9. Purpose Advice to phone and proxy vendors on how to support emergency calls Defines what protocols and mechanisms all phones and emergency call handling proxies must do Does not create any new protocols, extensions or mechanisms Currently, some overlap exists between framework and phonebcp, which will be resolved Generally, phonebcp will be “normative”, framework will be informative

10. Location Provides a list of protocols, currently DHCP and L7/HELD, possibly including LLDP-MED that ALL phones must implement Access network must implement at least one of them Phones must implement SIP Location and supply location on every call

11. Detecting emergency calls Phones should detect local (and home) emergency dialstrings –Local is a MUST –Home is a SHOULD Proxies MUST do it Request URI from element that detects should be urn:service:sos (.police/fire/medical if necessary)

12. SIP Signaling – Headers that must be provided Location (if access network provided location) Supported with location tag To: service urn or dialstring Request URI service URN Via with device Contact with URI of device or GRUU P-A-I or Identity

13. Midcall signaling Must allow REFER/Replaces Must not choke on conference stuff (IsFocus) Must support Session Timer If location can change (mobility) must supply a URI to subscribe to presence updates Device should not send BYE (PSAP terminates the call) Features to be disabled include 3-way calling, waiting, transfer, hold, outbound call blocking

14. NENA i3

15. NENA i3 builds on IETF Emergency Call work Next Generation of North American 9-1-1 Full upgrade of network and PSAP All PSAPs on IP network (Emergency Services IP Network) All calls answer as VoIP (gateways for legacy call originators) PSAPs are multimedia (voice, video, text)

16. Emergency Services IP Network IP network for all emergency services (PSAPs and responders) –All PSAPs will be connected to the ESInet –ESInets will have a set of defined services on the network available to any agency Connected to the Internet through a firewall (SBC) and probably one or more Emergency Services Routing Proxies ESRPs do hierarchical routing –Example: carrier LoST query may return URI of state level ESRP –State ESRP queries LoST with same location and may get URI of county level ESRP –County ESRP queries LoST and gets URI of PSAP –ESRPs also have policy engines that deal with congestion and failure Carriers may have VPN connections to ESInet

17. All Calls are answered as VoIP on ESInet Legacy CS wireline/wireless will use VoIP gateways Calls will have location added to SIP signaling and route with LoST This means all calls route the same way, and arrive at the PSAP with location and call-back info Still discussing who operates the gateways There will be transitions, but at the end, there is no Selective Router, only a remnant of the ALI (for wireline TN to address mapping) and no MSAG

18. PSAPs will be multimedia Voice G.711 May handle some mobile codecs directly Video –Probably H.263 –Definitely H.264 Text –interactive text –IM SIP Probably XMPP –SMS if we can work out the protocols) Pictures –would like to be able to get a picture taken and sent without dropping the call

19. LoST database will be provided by 9-1-1 authorities 9-1-1 authorities will provide LoST databases –Probably contracted Full MSAG-like validation for civic addresses Security mechanisms for local access network providers

20. Routing Phones should cache a location and a route (using LoST) Phones should refresh location and route at call time Proxies must route if emergency call and no route provided, and should verify the route if provided