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