Internet StandardsEmergency
Services
Hannes Tschofenig
Mail comments to Hannes.Tschofenig@nsn.com and/or ecrit@ietf.org.
Goal of this Presentation
• Understand the big picture of architectural
approaches
• Learn about technical challenges and their
solutions (on a high level basis)
• Obtain pointers to documents for further
reading (for more details)
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
Note
Throughout the subsequent slides we assume a IPbased PSAP to be present in the future emergency
services architecture.
Architectural descriptions for how to interworking
with legacy PSAPs can be, for example, found in the
NENA i2 specification.
– http://www.nena.org/media/File/08-001_20051205.pdf
The IETF emergency services architecture DOES NOT
require SIP being used between the User Agent and
the VSP.
Note, cont.
• Discussed specifications can be found here:
– IETF ECRIT Working Group
http://www.ietf.org/html.charters/ecrit-charter.html
– IETF GEOPRIV Working Group
http://www.ietf.org/html.charters/geopriv-charter.html
– IETF SIP Working Group
“Legacy End Points”
Location Information
Server
(2) Location
Routing
Database
(3)
Location +
Service
Identifier
(4)
PSAP URI
(1) INVITE
dial 1-2-2
Request URI: 122
To: 122
(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 RF 4967 or RFC
3966.
• Dial string recognition, location determination, route determination done
by SIP proxy
Disadvantages of Legacy Equipment
• 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.
Initial Upgrades to End Hosts
Location Information
Server
Routing Database
(3)
Location + Service
Identifier
(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
• Assumption:
– VSP is able to determine location of User Agent for routing the call.
– Typically, this requires contractual relationship between all IAPs/ISPs
and all VSPs, i.e., non-trivial to setup on a global scale.
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 determine emergency numbers and PSAP URI.
– SIP proxy may perform additional call routing checks.
… 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
• User types 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.
• 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
– GEOPRIV 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) as defined in the
Geopriv Working Group of IETF (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
Example: PIDF-LO with Geodetic Info
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
entity="pres:mike@seattle.example.com">
<dm:device id="mikepc">
<status>
<gp:geopriv>
<gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-43.5723 153.21760</gml:pos>
</gml:Point>
</gp:location-info>
<method>802.11</method>
<provided-by>www.example.com</provided-by>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
<ruleset-reference>https://www.example.com/myrules</ruleset-reference>
<note-well>These are my privacy rules</note-well>
<gp:usage-rules/>
</gp:geopriv>
</status>
<timestamp>2007-06-22T20:57:29Z</timestamp>
<dm:deviceID>mac:8asd7d7d70cf</dm:deviceID>
</dm:device>
</presence>
Example: PIDF-LO with Civic Info
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml“
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAd
dr"
entity="pres:mike@seattle.example.com">
<dm:device id="mikepc">
<status>
<gp:geopriv>
<gp:location-info>
<cl:civicAddress>
<cl:country>US</cl:country>
<cl:A1>New York</cl:A1>
<cl:A3>New York</cl:A3>
<cl:A6>Broadway</cl:A6>
<cl:HNO>123</cl:HNO>
<cl:LOC>Suite 75</cl:LOC>
<cl:PC>10027-0401</cl:PC>
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules/>
</gp:geopriv>
</status>
<timestamp>2007-06-22T20:57:29Z</timestamp>
<dm:deviceID>mac:8asd7d7d70cf</dm:deviceID>
</dm:device>
</presence>
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 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-wolfcivicaddresses-austria
*: 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.
RFC 4119 Civic Location Info
Label
Description
Example
country
The country is identified by the twoletter ISO 3166 code
US
A1
national subdivisions (state, region,
province, prefecture)
New York
A2
county, parish, gun (JP), district (IN)
King's County
A3
city, township, shi (JP)
New York
A4
city division, borough, city district,
ward, chou (JP)
Manhattan
A5
Neighbourhood, block
Morningside Heights
A6
Street
Broadway
PRD
Leading street direction
N, W
POD
Trailing street suffix
SW
RFC 4119 Civic Location Info, cont.
Label
Description
Example
STS
Street suffix
Avenue, platz, Street
HNO
House number, numeric part only
123
HNS
House number suffix
A, ½
LMK
Landmark or vanity address
Low Library
LOC
Additional location information
Room 543
FLR
Floor
5
NAM
Name (residence, business or office
occupant )
Joe’s Barbershop
PC
Postal code
10027-0401
RFC 5139 Civic Location Info
Label
Description
Example
BLD
Building (structure)
Hope Theatre
UNIT
Unit (apartment, suite)
12a
ROOM
Room
450F
PLC
Place-Type
Office
PCN
Postal community name
Leonia
POBOX
Post office Box (P.O. Box)
U40
ADDCODE
Additional Code
13203000003
SEAT
Seat (desk, cubicle, workstation)
WS 181
RD
Primary road or street
Broadway
RDSEC
Road section
14
RDBR
Road branch
Lane 7
RDSUBBR
Road sub-branch
Alley 8
PRM
Road pre-modifier
Old
POM
Road post-modifier
Extended
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/draft-ietf-geopriv-pdif-lo-profile
– 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 loosely aligned with 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
–
–
–
–
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)
HELD Example Request
POST https://lis.example.com:49152/location HTTP/1.1
Accept: application/held+xml,
application/xml;q=0.8,
text/xml;q=0.7
Accept-Charset: UTF-8,*
Content-Type: application/held+xml
Content-Length: 87
<?xml version="1.0"?>
<locationRequest
xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
Request for location information (no restrictions)
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" > <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" >
<locationType>civic</locationType>
</locationRequest>
Request civic location information
<locationType>geodetic</locationType>
</locationRequest>
Request geodetic location info
HELD Response (geodetic)
HTTP/1.x 200 OK
Server: Example LCS
Date: Tue, 10 Jan 2006 03:42:29 GMT
Expires: Tue, 10 Jan 2006 03:42:29 GMT
Cache-control: private
Content-Type: application/held+xml
Content-Length: 594
<?xml version="1.0" encoding="UTF-8"?>
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held" code="success" message="OK">
<presence xmlns="urn:ietf:params:xml:ns:pidf" entity="pres:3650n87934c@ls.example.com">
<tuple id="3b650sf789nd">
<status>
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">
<location-info>
<Point xmlns="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326">
<pos>-34.407 150.88001</pos>
</Point>
</location-info>
<usage-rules>
<retention-expiry> 2006-01-11T03:42:28+00:00</retention-expiry>
</usage-rules>
</geopriv>
</status>
<timestamp>2006-01-10T03:42:28+00:00</timestamp>
</tuple>
</presence>
</locationResponse>
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-capable
generalized identifier.
Location Information
Server
Request
Architecture
Location
Reference
SIP, HTTP, etc.
User Agent
(or proxy)
+ Location Reference
Location Recipient
• Examples:
– sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
– https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
LbyR Example
Request
<?xml version="1.0" encoding="UTF-8"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<locationType exact="true">locationURI</locationType>
</locationRequest>
LbyR Example Response
<?xml version="1.0" encoding="UTF-8"?>
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
code="success" message="OK">
<locationUriSet expires="2006-01-01T13:00:00">
<locationURI>
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>
sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com
</locationURI>
</locationUriSet>
</locationResponse>
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-winterbottom-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
(only authorized proxies are allowed to contact the LIS)
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
– Provised 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
– In a mobile environment when the end hosts location
may change 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
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 )
LoST Example
<findService> Query with geodetic location info
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"
serviceBoundary="value"
recursive="true">
<location id="6020688f1ce1896d" profile="geodetic-2d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>37.775 -122.422</p2:pos>
</p2:Point>
</location>
<service>urn:service:sos.police</service>
</findService>
LoST Example: <findService> Response
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66">
<displayName xml:lang="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
…
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="6020688f1ce1896d"/>
</findServiceResponse>
LoST Example
<findService> Query with civic location
<?xml version="1.0" encoding="UTF-8"?>
<findService xmlns="urn:ietf:params:xml:ns:lost1"
recursive="true" serviceBoundary="value">
<location id="627b8bf819d0bad4d" profile="civic">
<civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<A6>Otto-Hahn-Ring</A6>
<HNO>6</HNO>
<PC>81675</PC>
</civicAddress>
</location>
<service>urn:service:sos.police</service>
</findService>
Example: Location Validation
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
recursive="true"
validateLocation="true"
serviceBoundary="value">
<location id="627b8bf819d0bad4d" profile="civic">
<civicAddress
xmlns=
"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>DE</country>
<A1>Bavaria</A1>
<A3>Munich</A3>
<A6>Otto-Hahn-Ring</A6>
<HNO>6</HNO>
<PC>81675</PC>
</civicAddress>
</location>
<service>urn:service:sos.police</service>
</findService>
Request
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse
xmlns="urn:ietf:params:xml:ns:lost1">
<mapping>
…
</mapping>
<locationValidation>
<valid>country A1 A3 A6</valid>
<invalid>PC</invalid>
<unchecked>HNO</unchecked>
</locationValidation>
<path>
…
</path>
<locationUsed id="627b8bf819d0bad4d"/>
</findServiceResponse>
Response
(XML fragment)
Example:
listServices and listServicesResponse
<?xml version="1.0" encoding="UTF-8"?>
<listServices
xmlns="urn:ietf:params:xml:ns:lost1">
<service>urn:service:sos</service>
</listServices>
<?xml version="1.0" encoding="UTF-8"?>
<listServicesResponse
xmlns="urn:ietf:params:xml:ns:lost1">
<serviceList>
urn:service:sos.ambulance
urn:service:sos.animal-control
urn:service:sos.fire
urn:service:sos.gas
urn:service:sos.mountain
urn:service:sos.marine
urn:service:sos.physician
urn:service:sos.poison
urn:service:sos.police
</serviceList>
</listServicesResponse>
Request
Response
<listServicesByLocation> is a variation of <listServices> that includes location in
the query.
From a Protocol to an Architecture
• LoST is a protocol that runs between a LoST client and a
LoST server.
• There are, however, multiple ways to use and deploy it.
• Architecture description:
http://tools.ietf.org/html/draft-ietf-ecrit-mapping-arch
• For LoST usage in the NENA i3 architecture see
– http://tinyurl.com/63dvs4
• LoST deployment needs country-specific profiling to fit into
consider regional emergency service deployment circumstances.
Example questions:
– Who runs LoST servers?
– Who is allowed to put mapping data into the LoST server?
LoST Architecture, cont.
• http://tools.ietf.org/html/draft-ietf-ecrit-mapping-arch describes a
world-wide deployment of LoST for emergency services
usage.
– Unlike DNS it does not require a single root. There are many root
elements and they synchronize their mappings, for example, using
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-00.txt
– Like DNS it has redundancy mechanisms built-in
• Does not require support from the ISP/IAP
– But leaves the option todo so
• Dynamic LoST server discovery procedure
– via DNS (defined in http://tools.ietf.org/html/rfc5222)
– Via DHCP (defined in http://tools.ietf.org/html/rfc5223)
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 Region & Service URN  LoST server mappings
– Mapping Data:
• Maintains Region & Service URN  service URLs 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:psap@leonianj.gov
Fort Lee
sip:emergency@fortleenj.org
Teaneck
sip:police@teanecknjgov.org
Englewood englewoodnj.gov
Standardization of the emergency call
procedures for SIP.
IETF-based Emergency Call Procedure
• In the IETF architecture there is no requirement to have the
User Agent-to-VSP communication to use SIP.
– BUT: The PSAP is assumed to use SIP and hence protocol conversion to
SIP is necessary.
• The architecture aims to work in all contexts but the detailed
procedures of the emergency call itself depend on the
communication model.
– This particularly refers to the User Agent-to-VSP communication.
• The relevant documents are:
– http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-framework/
– http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-phonebcp/
• 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.
Responsibilities
• Location:
– Required LCPs by end hosts:
• DHCP Location options (RFC 4776 and RFC 3825)
• HELD (draft-ietf-geopriv-http-location-delivery)
• LLDP-MED
– ISP/IAP need to implement one of them.
• Identity:
– VSP must either use P-Asserted-Identity (RFC 3325) or the
SIP Identity (RFC 4474) mechanism to identify the
emergency caller.
• ES Call Routing:
– Responsibility of the VSP
Notes on Media Traffic
• RTP based media traffic RFC 3550 mandatory
• Minimum requirements for interoperability:
• Audio codec: G.711
Silence suppression not used.
• IM: RFC 3428 or RFC 3920
• Real-time text: RFC 4103
• Video: H.264 RFC 3984
– Better 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.
– Currently SRTP and key management of media traffic not required.
SIP Location Conveyance
– The GEOPRIV WG calls this a using protocol.
– SIP is such a using protocol, as defined in http://tools.ietf.org/html/draftietf-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“, "routing-entity“
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:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.example.com
;branch=z9hG4bK77i832k9
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.examplecom>;
tag=1928301774
Call-ID: a84b4c76e6Kr456@pc33.atlanta.com
Geolocation: cid:alice123@atlanta.example.com;
inserted-by=alice@atlanta.example.com;
recipient=endpoint
Supported: geolocation
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.example.com>
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.
Example: SIP Invite with Location by Value (2)
Bob
Alice
INVITE
--0a0
Content-Type: application/pidf+xml
Content-ID: cid:alice123@atlanta.example.com
…..
<gml:location>
<gml:coordinates>36.132N 115.151W
</gml:coordinates>
</gml:location>
…..
<method>802.11</method>
<provided-by>www.example.com</provided-by/>
…..
--0a0--
• XML fragment of multipart
MIME body
• Example geodetic location
Example: SIP Invite with Location by Value (3)
Bob
Alice
INVITE
--0a0
Content-Type: application/pidf+xml
Content-ID: cid:alice123@atlanta.example.com
...
<gp:geopriv>
<gp:location-info>
<cl:civilAddress>
<cl:country>US</cl:country>
<cl:A1>Nevada</cl:A1>
<cl:A3>Las Vegas</cl:A3>
<cl:HNO>399</cl:HNO>
<cl:A6>Convention Center</cl:A6>
<cl:STS>Drive</cl:STS>
<cl:PC>89109</cl:PC>
<cl:LMK>LVCC</cl:LMK>
<cl:RM>110</cl:RM>
<cl:civilAddress>
<gp:location-info>
...
--0a0--
• XML fragment of multipart
MIME body
• Example civic location
Example: SIP Invite with Location by Reference (1)
Alice
Bob
INVITE
INVITE sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/TCP pc33.atlanta.example.com
;branch=z9hG4bK77i832k9
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.example.com>;
tag=1928301774
Call-ID: a84b4c76e6Kr456@pc33.atlanta.ecample.com
Geolocation: sips:alice123@atlanta.example.com;
inserted-by=alice@atlanta.example.com;
Recipient=endpoint
Supported: geolocation
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.example.com>
Accept: application/sdp, application/pidf-xml
Content-Type: application/sdp
Content-Length: 243
• Example shows location
added by value.
• sips:alice123@atlanta.exampl
e.com represents the
location by reference
Example: SIP Invite with Location by Reference (2)
Bob
Alice
INVITE
200 OK
•
SIP/2.0 200 OK
Via: SIP/2.0/TCP sip:alice@atlanta.com
;branch=z9hG4bK77i832k9
To: Bob <sip:bob@biloxi.com>; tag=a6c85e3
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e6Kr456@pc33.atlanta.com
Geolocation: sips:alice123@atlanta.example.com
Supported: geolocation
CSeq: 314159 INVITE
Accept: application/sdp, application/pidf-xml
Content-Type: application/sdp
Content-Length: 142
(…Bob’s SDP here…)
200 OK may contain
either form of location
delivery (message body or
URI)
– Since Request had appropriate
Accept header
Location Hiding
– 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-hidingreq/
– 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-03.txt
– 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 authorizated
to make a call.
– Work assumes lower-layer procedures for omitting network access
authentication.
– High-level Impact:
• End host has to implement a specific VoIP profile
• SIP proxy has to be located in the access network.
– Technically complex and difficult to deploy.
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
• Still work todo? YES…
– Clear messages on how to share responsibilities (regulators)
– Start to implement (manufacturers & software vendors)
– Get engaged in early pilot to gain experience (VSPs, ISPs, IAPs)
Emergency Services Workshops:
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
discussions and information sharing in the context of emergency
services
– Come to a workshop: The next meeting is currently being planned.
Notifications will be sent to the coordination email list above.
• More information can be found at the main workshop page:
http://www.emergency-services-coordination.info
Backup Slides
IETF ECRIT: History (1/2)
1st ECRIT
WG
Meeting
1st ECRIT
Interim
Meeting
ECRIT
BOF
J F
2004
M
IETF#61
A
M
J
J
S
IETF#66
IETF#65
J F
2006
M
A
O
M
N
D
IETF#62
J F
2005
M
IETF
ECRIT –
3GPP
Workshop
5th ECRIT
WG
Meeting
2nd ECRIT
Interim
Meeting
4th ECRIT
WG
Meeting
A
2nd ECRIT
WG
Meeting
J
J
1st SDO
Emergency
Services
Workshop
A
S
N
D
ECRIT
WG
Meeting
IETF#63
M
J
J
IETF#64
A
S
O
7th ECRIT
WG
Meeting
M
A
M
D
8th ECRIT
WG
Meeting
IETF#68
J F
2007
N
IETF ECRIT
– IEEE
Workshop
6th ECRIT
WG
Meeting
IETF#67
O
A
3rd
J
J
A
2nd SDO
Emergency
Services
Workshop
S
O
N
D
3nd SDO
Emergency
Services
Workshop
IETF ECRIT: History (2/2)
11th ECRIT
WG
Meeting
10th ECRIT
WG
Meeting
IETF#72
IETF#71
J F
2008
M
A
M
J
J
A
S
IETF#73
O
9th ECRIT
WG
Meeting
4th SDO
Emergency
Services
Workshop
N
D
J F
2007
M
A
M
J
J
A
5th SDO
Emergency
Services
Workshop
S
O
N
D