draft-rosen-ecrit-emergency framework-00

Brian Rosen NeuStar CPa-060006

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

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

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

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)

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

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

draft-rosen-ecrit-phonebcp-01

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

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

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)

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

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

NENA i3

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)

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

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

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

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

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