Professional Documents
Culture Documents
Emergency
Services
Hannes Tschofenig
• 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
(3)
Location +
(4)
Service PSAP URI
(2) Location Identifier
• 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
Routing Database
Server
(3)
(4)
Location + Service
PSAP URI
Identifier
(2) Location
(1) INVITE (5) INVITE
Request URI:
SIP Request URI:
urn:service:sos Proxy urn:service:sos
dial 1-2-2 To: urn:service:sos To: urn:service:sos
VSP PSAP /
Route Header: PSAP URI
< Reference to PIDF-LO>
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.
Location Information
Fully Upgraded End Device
Server Routing Database
(2)
Location +
Service
(1) Location
(1)GPS Identifier
Info (3)
PSAP URI +
emergency
number
(4) INVITE (5) INVITE
dial 1-2-2 Request URI: SIP Request URI:
urn:service:sos Proxy urn:service:sos
To: urn:service:sos To: urn:service:sos PSAP
VSP
(Note: This is a Route Header: PSAP Route Header: PSAP URI
random IP URI <PIDF-LO>
device.) <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
• Location
– Format of location information
– Protocols for obtaining location
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 functionality-
reduced 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 XML-
based 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-wolf-
civicaddresses-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
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"/>
Location
Request Reference
• 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
ISP LIS VCI/VPI xyz.
(2b)
Location
Request
(2a) location for IP (2b)
address Location
10.162.93.203
(1) (5)
INVITE SIP INVITE
Request URI: Proxy Request URI:
urn:service:sos urn:service:sos
dial 1-1-2 To: urn:service:sos VSP To: urn:service:sos
Target PSAP /
Route Header: PSAP URI
Call
(Emergency <Location Reference>
Taker
Caller)
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
</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 <?xml version="1.0" encoding="UTF-8"?>
xmlns="urn:ietf:params:xml:ns:lost1" <findServiceResponse
recursive="true" xmlns="urn:ietf:params:xml:ns:lost1">
validateLocation="true" <mapping>
serviceBoundary="value"> …
<location id="627b8bf819d0bad4d" profile="civic"> </mapping>
<civicAddress <locationValidation>
xmlns= <valid>country A1 A3 A6</valid>
"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> <invalid>PC</invalid>
<country>DE</country> <unchecked>HNO</unchecked>
<A1>Bavaria</A1> </locationValidation>
<A3>Munich</A3> <path>
<A6>Otto-Hahn-Ring</A6> …
<HNO>6</HNO> </path>
<PC>81675</PC> <locationUsed id="627b8bf819d0bad4d"/>
</civicAddress> </findServiceResponse>
</location>
<service>urn:service:sos.police</service>
</findService>
Response
(XML fragment)
Request
Example:
listServices and listServicesResponse
<?xml version="1.0" encoding="UTF-8"?>
<listServices Request
xmlns="urn:ietf:params:xml:ns:lost1">
<service>urn:service:sos</service>
</listServices>
FG
Resolver
T2 Tree Tree
Node Node
seeker T1 (.de) T3
(.us) Tree (.at)
Leaf Leaf Leaf Leaf
Tree Node Node Node Node
Tree
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
broadcast (gossip)
FG
FG
FG
FG T1: .us
T2: .de
FG
resolver
seeker
313 Westview
Leonia, NJ US
T2
(.de) T3
T1
(.at)
(.us)
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
• ....
INVITE
Alice Bob
INVITE
Alice Bob
INVITE
• XML fragment of multipart
--0a0
Content-Type: application/pidf+xml
Content-ID: cid:alice123@atlanta.example.com
MIME body
... • Example civic location
<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--
Example: SIP Invite with Location by Reference (1)
Alice Bob
INVITE
INVITE
200 OK
• 200 OK may contain
SIP/2.0 200 OK either form of location
Via: SIP/2.0/TCP sip:alice@atlanta.com
;branch=z9hG4bK77i832k9 delivery (message body or
To: Bob <sip:bob@biloxi.com>; tag=a6c85e3
From: Alice <sip:alice@atlanta.com>;tag=1928301774 URI)
Call-ID: a84b4c76e6Kr456@pc33.atlanta.com – Since Request had appropriate
Geolocation: sips:alice123@atlanta.example.com
Supported: geolocation Accept header
CSeq: 314159 INVITE
Accept: application/sdp, application/pidf-xml
Content-Type: application/sdp
Content-Length: 142
J F M A M J J A S O N D J F M A M J J A S O N D
2004 2005
J F M A M J J A S O N D J F M A M J J A S O N D
2006 2007
4th ECRIT 1st SDO 7th ECRIT 2nd SDO 3nd SDO
WG Emergency WG Emergency Emergency
Services Services Services
Meeting Meeting
Workshop Workshop Workshop
IETF ECRIT: History (2/2)
J F M A M J J A S O N D J F M A M J J A S O N D
2008 2007
9th ECRIT
WG 5th SDO
Meeting Emergency
Services
4th SDO Workshop
Emergency
Services
Workshop