draft-rosen-ecrit-emergency-framework-00

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
  servicelocation
• 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 (urnservicesos) used to denote an
  emergency call
• Other markings will be required (to know its 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
  urnservicesos (.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