Transcript Standardizing IP-based Emergency Services

Standardizing IP-based
Emergency Services
Richard Barnes
BBN Technologies
IETF GEOPRIV Chair
Hannes Tschofenig
Nokia-Siemens
IETF ECRIT Chair
[email protected]
[email protected]
Goal of this Presentation
• Understand the big picture of IP-based emergency
services standardization.
• Learn about technical challenges and their solutions
• Obtain pointers to documents for further reading (for
in-depth study)
• I am here to help!  Ask questions
High-Level Emergency Services
Categorization
• Authority-to-Citizen
– Example: Tsunami warning
• Authority-to-Authority
– Example: Communication between emergency
personnel
Citizen-to-Authority
Note that some Standards Development Organizations (SDOs) use the term “individuals” instead of “citizen”.
Architectural Considerations
VoIP, Inc. (Application Service Provider)
Layer 7
Layer 3
Layer 1/2
ISP, Inc. (Internet Service Provider)
Last Mile, Inc. (Internet Access Provider)
End
Host
Architectural Considerations, cont.
• ISP/IAP has the technical means to know the precise
location of the end host.
• ASP, ISP and IAP are, in some cases, different entities.
• Internet is a world-wide network; end points go
everywhere – services come from everywhere.
• There are a multitude of different business models
with
– Many different protocols being used
– Long time to migrate and devices / networks with very
different capabilities
Assumptions about PSAP Capabilities
• Throughout the subsequent slides we assume
a IP-based PSAP to be present in the future
emergency services architecture.
• Architectural descriptions for how to
interwork with legacy PSAPs can, for example,
be found in the NENA i2 specification.
– http://www.nena.org/media/File/08001_20051205.pdf
– Other national variants (often derived from the
NENA i2 work exist)
Putting the Pieces together
• Work done in a couple of organizations
–
–
–
–
–
–
–
–
–
–
–
…
3GPP/3GPP2
Wimax Forum
NENA / EENA
OMA
ATIS ESIF
ETSI EMTEL
IETF
COCOM EGEA
E9-1-1 Institute
COMCARE
NIST
Clients
Access Networks
Origination Networks
Emergency Services IP Network (ESInet) Domains
Government
Services
3GPP, 3GPP2,
Wimax Forum
Legacy PSAP/Emergency
Responders
Legacy PSAP
Gateway
IM Clients
LISs
CSP
Call Server
SIP/H.323
Multimedia
Services
Public Web
Services
DNS
NG9-1-1 (i3) PSAP
ESInet
Originating
Border Control
Global Internet,
Private Networks
or IMS
Public Access
IP Networks
ESInet
clients
E-CSCF
(IMS) Location Validation
Web Interface
ECR
Web
Interfaces
Originating
ESRP
Terminating
Border Control
Legacy
Network
Gateway
Wireless/IP
Client
Emergency Call Routing &
Location Validation
Databases
Terminating
ESRP
Private Web
Services
Supplemental
Services
Databases
NG9-1-1 (i3) PSAP
Legacy CircuitSwitched Networks
PSTN client
Wireless/CS
Client
IETF
NENA/EENA
SIP Dependency
• The IETF emergency services architecture does NOT
require SIP being used between the User Agent and the
VSP.
– The usage of SIP is, however, documented for those using SIP.
– Currently, there is no specification for usage of non-SIP
protocols for emergency services.
– Although the 3GPP IMS architecture utilizes SIP their
communication model is different enough to cause
interoperability problems with plain IETF SIP clients. As such,
one could see the User Agent to VSP 3GPP specification as a
different SIP dialect.
• For interworking with IP-based PSAPs IETF and NENA
assume the usage of SIP by the VSP.
• Other organizations have a much stronger requirement
for SIP usage, such as 3GPP, and 3GPP2.
Today’s VoIP Emergency Service
Subscriber
Database
User
(1)
dial 1-1-2
(2)
(3)
Query for
location
Location
Info
VoIP Call
(5)
SIP
Proxy
VSP
VoIP Call
PSAP /
Call
Taker
Properties
• Systems largely build on user-provided location information
(and updates when necessary).
– Causes problems when update is not provided in time. Challenges with
nomadic usage and particularly with true mobility.
– Requires call-taker to verify the provided location information.
• Provided only by those who interwork with the PSTN (from a
regulatory point of view).
• VSP often hands calls over to emergency services
interconnection provider to interface PSAP.
• Emergency numbers are detected by the VSP. There is
typically no special support for emergency calling provided by
the User Agent software.
Automatic Location
• The ISP/IAP best knows the location of the end host.
– Note: GPS, and location databases maintained by
independent third parties do not require ISP/IAP.
– However, these mechanisms work only under certain
conditions. Hence, often seen as additional possibility
rather than a replacement for ISP/IAP provided location.
• Common understanding in the industry is that
automatic location will have to be provided for VoIP
emergency services in the mid- to long-term.
• The next slides assume that such an automatic
location capability is added for IP-based emergency
services.
“Legacy End Points”
Location Information
Server
(2) Location
Routing
Database
(3)
Location +
Service
Identifier
(4)
PSAP URI
(1) INVITE
dial 1-1-2
Request URI: 112
To: 112
(5) INVITE
SIP
Proxy
VSP
Request URI:
urn:service:sos
To: 112
Route Header: PSAP URI
< Reference to PIDF-LO>
PSAP /
Call
Taker
• Dial string provided by the end point may conform to RFC 4967 or RFC
3966.
• Dial string recognition, location determination, route determination done
by SIP proxy
Challenges
•
Two challenges appear with the mentioned
architecture:
1. How is the LIS discovered?
The IP address is the only information that is
available to the VSP. Hence, the IP address has to
be used to determine the ISP. Based on this info
the LIS run by the ISP has to be determined.
2. How is the emergency call routed to the nearest
PSAP?
Information about the PSAP boundaries need to be
available.
Disadvantages
•
When the emergency call is not recognized by the User Agent then
•
•
•
•
•
Call Waiting
Call Transfer
Three Way Call
Flash hold
Outbound Call Blocking
cannot be disabled.
– Callbacks from the PSAP may get blocked by the User Agent software.
– Privacy settings might disclosure identity information, even if not desired.
– Certain call features may not be supported either, such as REFER (for conference call and
transfer to secondary PSAP) or GRUU.
•
•
•
•
User Agents will not convey location information to the VSP (even if available at
the end host).
Only the emergency numbers configured at the VSP are understood. This may lead
to cases where a dialed emergency number is not recognized.
Using the IP address to find the ISP is challenging and may, in case of mobility
protocols and VPNs, lead to wrong results.
Privacy concerns might arise when a potentially large number of VSPs/ASPs are
able to retrieve location information from an ISP.
– It is likely that only authorized VSP/ASPs are allowed to be granted access. Unlikely to
work across country boundaries.
– Might require specific emergency services structure in order to work securely.
Privacy & Security
• Allowing other parties to retrieve location from an ISP raises authorization
challenges.
• BUT: Is the VSP really in need for location?
• Interestingly enough only to a limited extend (at a country level) when
there are not too many options to route calls exist. Examples:
– A) Very small number of stage 1 PSAP cover the entire country (UK).
– B) A single or a small number of ESRPs exist within the country that accept any
call and routing happens within the ES network automatically. (e.g., Sweden
and Lithuania).
– C) VSP routes calls via the ISP (e.g., IMS, DT)
• Learning the country where a specific host is located can be done based
on IP-to-Location lookups.
• With option (B) there are not necessarily changes to the emergency
services systems necessary as the number of PSAPs may be left
unchanged.
Initial Upgrades to End Hosts
Location Information
Server
Routing Database
(3)
Location + Service
Identifier
(0) Access
Network
Identifier
or LbyR
(4)
PSAP URI
(2) Location
(1)
dial 1-2-2
INVITE
Request URI:
urn:service:sos
To: urn:service:sos
SIP
Proxy
VSP
(5)
INVITE
Request URI:
urn:service:sos
To: urn:service:sos
Route Header: PSAP URI
< Reference to PIDF-LO>
PSAP /
Call
Taker
Assumptions
• End host detects emergency call (based on some preconfigured emergency numbers)
• End host may implement additional emergency services
features (e.g., disabling silence suppression).
• End host learns the domain of the access network (for
example using http://tools.ietf.org/html/draft-ietf-geoprivlis-discovery-11) and may be able to obtain a LbyR via
http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-dhcplbyr-uri-option/ or http://tools.ietf.org/wg/geopriv/draftietf-geopriv-http-location-delivery/.
• VSP is either able to resolve the LbyR in order to route the
call or to use the domain to query a LIS.
Fully Upgraded End Device
Location Information
Server
(1) Location
(1)GPS
Info
dial 1-2-2
(Note: This is a
random IP
device.)
Routing Database
(2)
Location +
Service
Identifier
(3)
PSAP URI +
emergency
number
(4) INVITE
Request URI:
urn:service:sos
To: urn:service:sos
Route Header: PSAP
URI
<PIDF-LO>
SIP
Proxy
VSP
(5) INVITE
Request URI:
urn:service:sos
PSAP
To: urn:service:sos
Route Header: PSAP URI
<PIDF-LO>
• End host obtains location information necessary for call routing
• End host uses LoST to learn locally available emergency numbers. It may
also learn the PSAP URI but this function may also be provided by the VSP.
Characteristics
• Locally available LoST servers improve reliability. LoST
servers can, however, be deployed everywhere.
• LoST servers provide dial string recognition
• Local network characteristics (e.g., enterprise
emergency network) can be considered using locally
deployed LoST servers.
• If connectivity to VSP does not work direct
messaging to PSAP possible (assumes certain SIP
profile).
… subsequent slides talk about some
of the components in more detail
• Identifying an emergency call
• Location
– Format of location information
– Protocols for obtaining location
• Emergency Call Routing
• Standardization of the emergency call procedures for
SIP.
Identifying an Emergency Call
Emergency Numbers
Emergency Numbers used worldwide,
see http://www.sccfd.org/travel.html
Emergency numbers vary in countries. Example: 9-1-1 for North America, 1-1-2 for Europe.
Some countries use separate numbers for ambulance/police/fire; others don’t
Service URNs
• Emergency caller enters emergency dial string into
the user interface
• On the protocol level an emergency number
independent scheme is desired to mark a call as an
emergency call.
 This lead to the work on Service URNs. Work done in the ECRIT working
group: http://www.ietf.org/html.charters/ecrit-charter.html
• Service URN registry established in
http://tools.ietf.org/html/rfc5031
– Examples: urn:service:sos, urn:service:sos.ambulance,
urn:service:sos.fire, urn:service:sos.poison,
urn:service:sos.police
Home and Visited Emergency Numbers
• Required to support both home and visited
emergency number
– e.g., for an American traveler who is visiting
Europe, both 9-1-1 and 1-1-2 should be
recognized as emergency
• How does the User Agent learn about
emergency numbers:
– Home Emergency Number: User can learn this
number through LoST* or device configuration.
– Visited Emergency Number: Obtained
dynamically via LoST*
(*): LoST is a protocol, more on later slides.
Location
Encoding of Location Information
– The GEOPRIV WG http://www.ietf.org/html.charters/geoprivcharter.html uses two formats for location information
encoding.
• Binary Format
• XML-based Format
– For bandwidth constraint environments a functionalityreduced binary encoding is used (e.g., DHCP, link layer
protocols) and for application protocols the XML encoding is
preferred.
– The XML encoding is based on the Presence Information Data
Format (PIDF) for Location Objects (LO), or simply PIDF-LO.
– PIDF-LO uses the Geography Markup Language (GML)
developed by OGC for describing geodetic information.
PIDF-LO: RFC 4119
– The Presence Information Data Format (PIDF) is an XMLbased format for presence (RFC 3863)
– A PIDF document contains identity information (as part of
the ‘entity’ attribute).
– Extends PIDF to accommodate new functionality:
• <location-info> Element
– Encapsulates location information
– GML 3.0 <feature.xsd> schema (mandatory-to-implement)
– Supports civic location format (optional-to-implement)
• <method> Element
– Describes the way location information was derived or discovered.
– Example: <method>gps</method>
– Registry available at: http://www.iana.org/assignments/method-tokens
• <provided-by> Element
– Entity or organization that supplied this location information
• <usage-rules> Element
– Used to indicate privacy preferences
More on Civic Information
– Initially civic location was specified for DHCP in RFC
4776* (http://www.ietf.org/rfc/rfc4776.txt)
– RFC 4776 uses a binary format.
– With RFC 4119* (PIDF-LO) for some of the RFC 4776
civic elements an XML encoding was specified.
– With http://www.ietf.org/rfc/rfc5139.txt the
document was revised and new civic tokens were
added to be able to express addresses in Asia.
– Note: Not every jurisdiction needs to make use of all
civic tokens. An example of a profiling for Austria is
described in http://tools.ietf.org/html/draft-ietfgeopriv-civic-address-recommendations
*: Note that the content of RFC 4776 was developed before the work on PIDF-LO (RFC 4119). It was,
however, faster to finish the standardization work on PIDF-LO.
Location Shapes for Geodetic Info
– Location determination techniques produce location information in different
shape types. The specification uses the GML-based format for describing the
shapes: http://tools.ietf.org/html/rfc5491
– The following location shapes are described:
– Point (2d and 3d)
– Polygon (2d)
– Circle (2d)
– Ellipse (2d)
– Arc Band (2d)
– Sphere (3d)
– Ellipsoid (3d)
– Prism (3d)
– The document additionally makes a couple of simplifying restrictions
(e.g., coordinate reference systems).
– Finally, it also describes how PIDF-LO documents are created when location
information from multiple sources is available.
– Format is aligned with functionality provided by OMA and 3GPP specifications.
Obtaining Location Information
1) Target has location information
• Manual configuration or GPS (without help of the network)
2) Target wants to obtain location info from a LIS in the
access network (see LCPs on subsequent slide)
3) Target obtains location from a location server in the user’s
home network
• OMA MLS/SUPL: http://tinyurl.com/6qdbxt
4) Location Server from 3rd Party Providers using Global Cell-ID
database, BSSID database
Location Configuration Protocols
(LCPs)
Location Information
Server
Target
Request Location
Location
• Assumes that some entity in the access network knows the location of the
Target.
• LIS is topologically close to the Target.
• Request from the Target to the LIS
needs to contain identifier to lookup location information
• Identifier will typically be the IP address
• Protocol exchange may happen at different layers. E.g.:
–
–
–
–
HTTP in case of HELD
IP in case of DHCP
On top of the link layer but below IP (LLDP-MED)
Link layer
LCPs, cont.
•
Link layer mechanisms
(e.g., various extensions to IEEE link layer protocols)
LLDP-MED
– http://tinyurl.com/5eqlpq
– http://tinyurl.com/5o3yxk
– http://tinyurl.com/6hvag5
•
DHCP (civic and geospatial)
– RFC 4776 for civic location information (slides at http://tinyurl.com/6oj52t)
http://www.ietf.org/rfc/rfc4776.txt
– RFC 3825 for geodetic location information (slides at http://tinyurl.com/6jgchf)
http://www.ietf.org/rfc/rfc3825.txt
•
Application Layer Location Configuration Protocol
(e.g., HELD http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery)
• OMA MLS/SUPL: http://tinyurl.com/6qdbxt
Location by Reference
• Previous slides describe how location can be passed
around per value.
• But there are examples when this is not desired.
– E.g., when location frequently changes
• Solution approach:
– Instead of retrieving location information per value a
reference is obtained.
– This reference can be resolved to a location object (more
than once) and may yield to fresh location
– Access control can also be enforced.
• The reference plays the role of a privacy-enhancing
generalized identifier.
Location Information
Server
Request
Architecture
Location
Reference
SIP, HTTP, etc.
User Agent
(or proxy)
+ Location Reference
Location Recipient
• Examples:
– sips:[email protected]
– https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
Identifier Extensions
• HELD allows the source IP address of the HELD request
to be used for the location lookup.
• Sometimes more flexiblity with regard to the identifier
choice is needed
 „HELD Identity Extensions“ Document:
http://tools.ietf.org/id/draft-ietf-geopriv-held-identity-extensions
• Typical usage:
– LIS-to-LIS communication scenarios (in DSL wholesale
environments)
http://tools.ietf.org/html/draft-winterbottom-geopriv-held-lis2lis-bcp
– SIP proxy-to-Location Server communication
Example
IAP LIS
Request
(2a) location for
VCI/VPI xyz.
ISP LIS
(2b)
Location
Request
(2a) location for IP
address
10.162.93.203
(2b)
Location
(1)
dial 1-1-2
Target
(Emergency
Caller)
INVITE
Request URI:
urn:service:sos
To: urn:service:sos
SIP
Proxy
VSP
(5)
INVITE
Request URI:
urn:service:sos
To: urn:service:sos
Route Header: PSAP URI
<Location Reference>
PSAP /
Call
Taker
De-Referencing
• The Location Recipient obtains the URI and needs to
resolve it to location information.
• Dereferencing protocol depends on the URI scheme:
– SIP Subscribe / Notify (in case of a SIP URI)
– HTTP (in case of HTTP URI)
(+ secure versions being used; HTTPS and SIPS)
• Best current practice document for HTTP-based
Location URIs:
– http://tools.ietf.org/id/draft-winterbottom-geopriv-deref-protocol
– Provides polling capabilities
• For SIP the SIP presence event package is used to obtain
location information
– Offers also asynchronous notifications ( next slide)
Rate Limiting Asynchronous
Notifications of SIP
•
•
•
When location may change regularly then it is useful to restrict
the number of asynchronous notifications being sent.
SIP offers asynchronous message (with the PubSub concept) and
a SUBSCRIBE message may contains rate limiting filters.
Document is available with:
http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-loc-filters/
•
Features:
1. Object moves more than a specific distance horizontally or vertically since
the last notification
2. Object exceeds a specific speed
3. Object enters or exits pre-defined regions
4. one or more of the values of the specified address labels has changed
5. Reduction of the rate at which messages that are being sent.
Emergency Call Routing
Finding the closest PSAP
Location Information
+
Service URN
Emergency Number
+
Service URN
+
(PSAP) URI
Location-to-Service Translation (LoST) is an
XML-based query and response protocol
running on top of HTTP.
+
Service Boundary
Features
• Protocol specification available with
– http://tools.ietf.org/html/rfc5222
• Satisfies the requirements for mapping protocols:
– http://tools.ietf.org/html/rfc5012
• Provides civic address validation
– Returns XML tag names of components (classified into <valid>, <invalid>
and <unchecked>)
• Offers recursive and iterative query resolution
• Service boundary may be returned via reference or by value.
• Functionality for listing available service URNs and listing service
URNs per location.
• Supports extensible location profiles. Currently 2 profiles are
available:
– geodetic-2d (offers Point, Polygon, Circle, Ellipse, ArcBand)
– civic (based on http://tools.ietf.org/html/rfc5139 )
From a Protocol to an Architecture
• LoST is a protocol that runs between a LoST client and a LoST
server.
• Not sufficient when calls from anywhere need to find their way to
the right PSAP.
• RFC 5582 describes a global mapping architecture using LoST.
– Unlike DNS it does not require a single root. There are many root elements
and they synchronize their mappings, for example, using
http://tools.ietf.org/html/draft-ietf-ecrit-lost-sync
– Like DNS it has redundancy mechanisms built-in
• LoST is a core building block for the NENA i3 architecture, see
http://tinyurl.com/63dvs4
• There are multiple ways to deploy LoST. LoST deployment needs countryspecific profiling to historical deployment differences and other preferences.
Example questions:
–
–
–
–
Who runs authoritative LoST servers? Who runs caches?
Who is allowed to put mapping data into the LoST server?
Who is allowed to access LoST servers?
How many LoST servers are needed? Is there a synchronization between them?
LoST Architecture, cont.
• Does not require support from the ISP/IAP
– But leaves the option to do so
• Dynamic LoST server discovery procedure available:
– via DNS (defined in http://tools.ietf.org/html/rfc5222)
– Via DHCP (defined in http://tools.ietf.org/html/rfc5223)
• Open Source code to play with:
– Pointer to code from Columbia University http://www.tschofenig.priv.at/wp/?p=486
Terminology
Forest
Guide
FG
FG
FG
FG
FG
Resolver
T2
seeker
T1
(.de)
(.us)
Tree
Tree
Tree
Tree
Node
Tree
Node
T3
(.at)
Leaf
Node
Leaf
Node
Leaf
Node
Leaf
Node
Terminology
• Seekers: Consumers of mapping data and may cache
responses. Don’t act as servers.
• Resolvers: Know how to contact FGs and tree nodes. May
cache results. Does not have authoritative mappings
configured.
• Forest Guide: Knows about the coverage region of all trees.
Do not provide mapping data themselves. Redirects only to
tree nodes.
• Tree Node: Maintains mapping data and coverage regions.
Knows about the coverage region of all its child nodes.
• Leaf Nodes only maintain mapping data. No coverage region
data.
• From an implementation point of view:
– Coverage Region:
• Maintains {PSAP Boundary & Service URN LoST server URI} mappings
– Mapping Data:
• Maintains {PSAP Boundary & Service URN  PSAP URI } mappings
Example
FG
FG
FG
broadcast (gossip)
FG
T1: .us
FG
T2: .de
resolver
seeker
313 Westview
Leonia, NJ US
T2
T1
(.us)
(.de)
T3
(.at)
Example
• When query hits T1 tree then it finally travels to a node that knows
about the LoST servers responsible for New Jersey:
•
•
C A1 A2
A3 LoST server name
•
US NJ Atlantic * atlantic.nj.example.org/sos
•
US NJ Bergen * bergen.nj.example.org/sos
•
US NJ Monmouth * monmouth.nj.example.org/sos
•
US NJ Essex * essex.nj.example.org/sos
•
US NJ Essex Newark newark.example.com/sos
•
....
• The LoST server at bergen.nj.example.org then contains the following
data:
•
•
•
•
•
•
country A1 A2
US
NJ Bergen
US
NJ Bergen
US
NJ Bergen
US
NJ Bergen
….
A3
PSAPs and further LoST servers
Leonia
sip:[email protected]
Fort Lee
sip:[email protected]
Teaneck
sip:[email protected]
Englewood englewoodnj.gov
Standardization of the emergency call
procedures for SIP.
IETF-based Emergency Call Procedure
• The architecture describes the final envisioned emergency
services deployment.
– This particularly refers to the sharing of responsibilities (end host, VSP,
ISP).
• The relevant documents are:
– http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-framework/
– http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-phonebcp/
– These documents ALSO describe the VSP-to-PSAP interaction.
• draft-ietf-ecrit-phonebcp makes use of the Service URN and
SIP Location Conveyance http://tools.ietf.org/wg/sip/draftietf-sip-location-conveyance/ as protocol mechanisms.
IETF - Multi-Media Support
• RTP based media traffic RFC 3550 mandatory
• Minimum requirements:
•
•
•
•
Audio codec: G.711
Instant Messaging: RFC 3428 or RFC 3920
Real-time text: RFC 4103
Video: H.264 RFC 3984
• Better codecs/features can be negotiated via SIP offer/answer
RFC 3264.
• Testing: INVITE requests to a service urn with a urn parameter
of "test" indicates a request for an automated test.
– Example: "urn:service.sos.fire;test“
– Response may include a text body (text/plain) with PSAP identity, the
requested service, and the location reported with the call.
• Media security mechanisms (SRTP & key management)
currently not mandated.
SIP Location Conveyance
• Mechanism to carry location by value and by reference in SIP
http://tools.ietf.org/html/draft-ietf-sip-location-conveyance
• Defines the Geolocation header:
– Points to location per value (using a cid:) or contains a reference (e.g., sips:)
• Geolocation header may contain additional parameters:
– inserted-by parameter: Indicates which entry added location to the
message ("endpoint" or "server“)
– used-for-routing parameter: Used when location was used for routing
– recipient parameter: Indicates intended recipient ("endpoint“, "routingentity“ or "both“)
• New geolocation option tag: To indicate support for the this
extension by UAs in Require, Supported and Unsupported headers
(RFC 3261)
• New error message (424 Bad Location Information)
– Contains addition error value
– Node identification of the entity that experienced the location-based error
– Human readable error text pre-defined in the draft
• Defines sip/sips/pres as a dereference scheme
Example: SIP Invite with Location by Value (1)
Bob
Alice
INVITE
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.example.com
;branch=z9hG4bK77i832k9
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;
tag=1928301774
Call-ID: [email protected]
Geolocation: cid:[email protected];
[email protected];
recipient=endpoint
Supported: geolocation
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Accept: application/sdp, application/pidf-xml
Content-Type: multipart/mixed; boundary=0a0
Content-Length: 543
sdp
geolocation (if as a message body)
•
Example shows
location added by
value. cid: points to
location in the body.
Location Hiding
• Let us assume:
– Network operator does not want to provide end host with precise
location information.
– Operator is only willing to provide enough information to
accomplish location based routing to the PSAP.
• Problem Statement and Requirements provided with
– http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-location-hiding-req/
• REMINDER: Two types of location information are used for
emergency services:
(a) Location Information for Dispatch
(b) Location Information for Routing
• This is not about hiding location towards the PSAP!
• Solution proposal available with
– http://tools.ietf.org/html/draft-barnes-ecrit-rough-loc
Unauthenticated Emergency Services
• Reference: http://tools.ietf.org/id/draft-schulzrinne-ecritunauthenticated-access
• Cases:
– The emergency caller does not have credentials for access
to the network but still has credentials for his VoIP provider.
– The emergency caller has credentials for network access
but does not have credentials for a VoIP provider.
– The emergency caller has valid credentials but is not
authorized to make a call.
• Work assumes lower-layer procedures for omitting network
access authentication.
• Technically complex and difficult to deploy. Introduces security
vulnerabilities.
Callback
• Marking of Calls initiated by Public Safety Answering Points
(PSAPs)
– Touches the authority-to-citizen topic
– Callback is an ordinary call, i.e. no preferential treatment. Call could
get blocked, re-directed or ignored.
• Phone BCP describes a basic solution:
– Store information about the participating communication parties of
the emergency call for a limited period of time
– When call callback arrives check against stored state.
– Acts similar to stateful packet filtering firewalls.
• Problem statement, requirements and solution strawmans are
provided in http://tools.ietf.org/id/draft-schulzrinne-ecritpsap-callback
A few words about other organizations
NENA
•NENA was founded in 1981 on the principle of “One Nation,
One Number,” in order to help assure ubiquitous 9-1-1
service across the United States of America
•Today, that initial vision has largely been realized with
better than 99% of the U.S. population now covered by some
form of 9-1-1 service
•But, the effort started anew in 2001 with the NENA Future
Path Plan and in 2003 with the start of development of NG91-1, the IP-based replacement for Enhanced 9-1-1
•See http://www.nena.org for further description;
membership required to access work-in-progress documents.
Mission Statement
• NENA, through public and private industry
partnerships, is committed to the
technological advancement, availability,
accessibility and implementation of a reliable
system for requesting emergency assistance.
• In carrying out its mission, NENA promotes:
Research, planning, training and education.
77
Important technical working groups
• NENA i2.5
– Revises NENA i2
• NENA Long Term Definition
– Development of NENA i3
– A number of relevant sub-groups, such as
additional data group, ECRF LVF, etc.
– NENA Text to NG911 Group
NENA & NG9-1-1:
A Commitment for Multi-Media
•
•
•
•
Audio/voice calls with data
Text messages/calls with data
Interactive video calls with data
Interactive video with interactive audio/voice &
interactive text – with data
• Sensors/other devices with interactive voice/audio, text
&/or video – with data
• Sensors/other devices (no interactive voice/audio, text
or video) with data
* Data when referenced above can include non-interactive
text, video, pictures and audio recordings
79
i3 Functional Architecture
Client
Access
Network
Originating
Network
Emergency
Services
Interconnect
Public Packet-based
Networks
(e.g., 3G, WiMax)
Text
LVF
IP PSAP
Government
ECRF
LIS
Responder
ECRF
ESRP
Voice
Internet
Emergency Services
IP Network (ESInet)
i3 PSAP
BCF
Video
Supplemental
Data
LVF
Legacy Networks
(e.g., Wireless/CS & Wireline)
Legacy PSAP
GW
Legacy
Network GW
Multimedia
Out of Scope
In Scope of i3
Requires Ops input
EENA NG112 TC
•
•
•
•
EENA: http://www.eena.org
Technical discussion group within EENA
Phone conference calls (every 2 weeks)
Google Groups Mailing List and Document
Storage.
• Document sharing agreement between NENA
and EENA exists.
– Idea: Re-use existing work (in particular NENA i3)!
The EENA NG112 Project –
Long Term View
Technical
Operations
Education
Partnership
Transition
• Technical Committee: Technical development with the
NG112 TC.
• Operations Committee: Operations development including
interoperability testing, certification, and registry
maintenance.
• Education Program: Education for a broad spectrum of
entities and people
• Partner Program: Addresses policy issues around NG112,
coordinating with the EENA legal group.
• Transition Committee: Best current practice guidelines
around transition & implementation
Next Steps?
• Review NENA i3 specification (Requirements, Stage 2 and
Stage 3 documents)
• Profile text according to European deployment environment.
• Interact with NENA members to clarify, modify and enhance
specification
• May need to create additional sub-groups to tackle the work
in an efficient manner
– Non-IP-based PSAPs (aka NENA i2.5)
– Civic location address group
• Goal:
– Get requirements document finished by Nov 2009
– Finish architecture document by Jan 2010
How to contribute?
• Send a mail to Gary ([email protected]), Roger
([email protected]) or myself ([email protected]).
– We will add you to the mailing list and configure the access control
lists.
• Share your thoughts about technical aspects with others in
the group.
• Give presentations about IP-based emergency services
aspects.
• Submit text contributions.
• Tell us about implementation, pilots, and deployment work:
What worked? What didn’t?
• Volunteer to drive the work forward as a member or chair of a
group.
How to get
involved?
• The Emergency Services Workshop is not a membership
organization, but rather an ad-hoc forum for discussions
about emergency services. There are no entrance
requirements and no fees (other than a small amount to cover
meeting costs). To get involved:
– Join the e-mail list: Subscribe to the mailing list
(https://lists.cs.columbia.edu/cucslists/listinfo/es-coordination) for
information sharing in the context of emergency services
– Come to a workshop: Info about next meeting, see subsequent slide.
• More information can be found at the main workshop page:
http://www.emergency-services-coordination.info
• Next workshop to be in March/April 2010, in US or Europe
Conclusion
• Standardizing protocols for emergency services
means
– facing technical challenges
– learning to deal with an unclear regulatory
framework
– balancing conflicting interests of the stakeholders
along the entire value chain
– working with a large number of players and
instituations
Still work to do? YES…
• Work with regulators and governments to get a better
understanding of the responsibilities and funding models
• Use the available open source code; help to improve it and
contribute your own code
• Get engaged in early pilot activities
• Participate in technical groups (IETF ECRIT
http://www.ietf.org/html.charters/ecrit-charter.html, NENA,
EENA, etc.)
• Contribute your research results