Transcript draft-rosen-ecrit-framework-00

draft-rosen-ecrit-emergencyframework-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