Internet Standards-Emergency

ServicesHannes 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)

• Authority-to-Citizen– Example: Tsunami warning

• Authority-to-Authority– Example: Communication between emergency

personnel

Citizen-to-Authority

High-Level Emergency Services Categorization

Note that some Standards Development Organizations (SDOs) use the term “individuals” instead of “citizen”.

Architectural Considerations

Last Mile, Inc. (Internet Access Provider)

ISP, Inc. (Internet Service Provider)

VoIP, Inc. (Application Service Provider)Layer 7

Layer 1/2

Layer 3

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

NoteThroughout the subsequent slides we assume a IP-based 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 Grouphttp://www.ietf.org/html.charters/ecrit-charter.html

– IETF GEOPRIV Working Grouphttp://www.ietf.org/html.charters/geopriv-charter.html

– IETF SIP Working Group

PSAP / Call Taker

Routing Database

VSP

(2) Location

Location + Service Identifier

(3)

PSAP URI(4)

INVITE Request URI: 122 To: 122

(1) (5)

dial 1-2-2

“Legacy End Points”Location Information Server

• 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

INVITERequest URI: urn:service:sosTo: 112

Route Header: PSAP URI < Reference to PIDF-LO>

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.

PSAP / Call Taker

(2) Location

Location + Service Identifier

(3)

PSAP URI(4)

(1) (5)

Initial Upgrades to End Hosts

• 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 Server

INVITERequest URI: urn:service:sosTo: urn:service:sos

INVITERequest URI: urn:service:sosTo: urn:service:sos

Route Header: PSAP URI < Reference to PIDF-LO>

dial 1-2-2

Routing Database

VSP

SIP Proxy

Fully Upgraded End Device

• 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.

Routing Database

PSAP

(1) Location

Location + Service Identifier

(2)

PSAP URI + emergency number

(3)

(4) (5)

Location Information Server

INVITERequest URI: urn:service:sosTo: urn:service:sosRoute Header: PSAP URI <PIDF-LO>

INVITERequest URI: urn:service:sosTo: urn:service:sosRoute Header: PSAP URI <PIDF-LO>

dial 1-2-2

(Note: This is a random IP device.)

(1)GPS Info

VSP

SIP Proxy

… 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 NumbersEmergency 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

• 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.

Home and Visited Emergency Numbers

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:civicAddr" 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 InfoLabel Description Example

country The country is identified by the two-letter 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 InfoLabel 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.

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 theaccess 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

Obtaining Location Information

Location Configuration Protocols (LCPs)

• 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

Location Information Server

Request Location

Location

Target

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 RequestPOST https://lis.example.com:49152/location HTTP/1.1Accept: application/held+xml, application/xml;q=0.8, text/xml;q=0.7Accept-Charset: UTF-8,*Content-Type: application/held+xmlContent-Length: 87

<?xml version="1.0"?><locationRequest

xmlns="urn:ietf:params:xml:ns:geopriv:held"/>

<?xml version="1.0" encoding="UTF-8"?>

<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" >

<locationType>civic</locationType>

</locationRequest>

<?xml version="1.0" encoding="UTF-8"?>

<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" >

<locationType>geodetic</locationType>

</locationRequest>

Request civic location information Request geodetic location info

Request for location information (no restrictions)

HELD Response (geodetic)HTTP/1.x 200 OKServer: Example LCSDate: Tue, 10 Jan 2006 03:42:29 GMTExpires: Tue, 10 Jan 2006 03:42:29 GMTCache-control: privateContent-Type: application/held+xmlContent-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.

Architecture

SIP, HTTP, etc.

+ Location Reference Location Recipient

Location Reference

User Agent(or proxy)

Location Information Server

Request

Location Information

• Examples:– sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com– https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o

Location Reference

LbyR ExampleRequest

<?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)

(2a)Request location for IP address 10.162.93.203

Example

PSAP / Call Taker

Target

(Emergency Caller)

(1) (5)

dial 1-1-2

ISP LIS

INVITERequest URI: urn:service:sosTo: urn:service:sos

INVITERequest URI: urn:service:sosTo: urn:service:sos

Route Header: PSAP URI <Location Reference>

(2b)Location

VSP

SIP Proxy

IAP LIS

(2a)Request location for VCI/VPI xyz.

(2b)Location

• 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)

De-Referencing

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

Service URN

Location Information

Finding the closest PSAP

+

(PSAP) URI

Service URN

Service Boundary

+

+

Emergency Number

+

Location-to-Service Translation (LoST) is an XML-based query and response protocol running on top of HTTP.

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>

<?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>

Request

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.

• 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?

From a Protocol to an Architecture

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)

T3

(.at)

Terminology

T1

(.us)

T2

(.de)

FG

FG

FG

FG

FG

Resolver

seeker

Forest Guide

Tree

Tree

Tree

Tree Node

Tree Node

LeafNode

LeafNode

LeafNode

LeafNode

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

T1

(.us)

T2

(.de) T3

(.at)

FG

FG

FGFG

FG

broadcast (gossip)

T1: .us

T2: .de

resolver

seeker313 Westview

Leonia, NJ 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• ....

• The LoST server at bergen.nj.example.org then contains the following data:

• country A1 A2 A3 PSAPs and further LoST servers• US NJ Bergen Leonia sip:psap@leonianj.gov• US NJ Bergen Fort Lee sip:emergency@fortleenj.org• US NJ Bergen Teaneck sip:police@teanecknjgov.org• US NJ Bergen 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/draft-ietf-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.

– The GEOPRIV WG calls this a using protocol.– SIP is such a using protocol, as defined in

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“, "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

SIP Location Conveyance

Alice

Example: SIP Invite with Location by Value (1)Bob

• Example shows location added by value. cid: points to location in the body.

INVITE sip:bob@192.168.10.20 SIP/2.0Via: SIP/2.0/TCP pc33.atlanta.example.com ;branch=z9hG4bK77i832k9Max-Forwards: 70To: Bob <sip:bob@biloxi.com>From: Alice <sip:alice@atlanta.examplecom>; tag=1928301774Call-ID: a84b4c76e6Kr456@pc33.atlanta.com Geolocation: cid:alice123@atlanta.example.com;inserted-by=alice@atlanta.example.com;

recipient=endpoint Supported: geolocation CSeq: 314159 INVITEContact: <sip:alice@pc33.atlanta.example.com>Accept: application/sdp, application/pidf-xmlContent-Type: multipart/mixed; boundary=0a0Content-Length: 543

INVITE

geolocation (if as a message body)

sdp

--0a0Content-Type: application/pidf+xmlContent-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--

Alice

Example: SIP Invite with Location by Value (2)

Bob

INVITE

• XML fragment of multipart MIME body

• Example geodetic location

Alice

Example: SIP Invite with Location by Value (3)

Bob

INVITE

--0a0Content-Type: application/pidf+xmlContent-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

Alice

Example: SIP Invite with Location by Reference (1)

Bob

INVITE sip:bob@192.168.10.20 SIP/2.0Via: SIP/2.0/TCP pc33.atlanta.example.com ;branch=z9hG4bK77i832k9Max-Forwards: 70To: Bob <sip:bob@biloxi.com>From: Alice <sip:alice@atlanta.example.com>; tag=1928301774Call-ID: a84b4c76e6Kr456@pc33.atlanta.ecample.com Geolocation: sips:alice123@atlanta.example.com;inserted-by=alice@atlanta.example.com; Recipient=endpointSupported: geolocation CSeq: 314159 INVITEContact: <sip:alice@pc33.atlanta.example.com>Accept: application/sdp, application/pidf-xmlContent-Type: application/sdpContent-Length: 243

INVITE

• Example shows location added by value.

• sips:alice123@atlanta.example.com represents the location by reference

Alice Bob

200 OK • 200 OK may contain either form of location delivery (message body or URI)– Since Request had appropriate

Accept header

SIP/2.0 200 OKVia: SIP/2.0/TCP sip:alice@atlanta.com ;branch=z9hG4bK77i832k9To: Bob <sip:bob@biloxi.com>; tag=a6c85e3From: Alice <sip:alice@atlanta.com>;tag=1928301774Call-ID: a84b4c76e6Kr456@pc33.atlanta.com Geolocation: sips:alice123@atlanta.example.com Supported: geolocation CSeq: 314159 INVITEAccept: application/sdp, application/pidf-xmlContent-Type: application/sdpContent-Length: 142

(…Bob’s SDP here…)

INVITE

Example: SIP Invite with Location by Reference (2)

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-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-ecrit-unauthenticated-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)

J F M A M J J A S O N D J F M A M J J A S O N D2004 2005

ECRIT BOF

1st ECRITWG

Meeting

1st ECRIT Interim Meeting

IETF#63

J F M A M J J A S O N D J F M A M J J A S O N D2006 2007

2nd ECRIT Interim Meeting

4th ECRIT WG

Meeting

5th ECRIT WG

Meeting

IETF#62IETF#61

2nd ECRITWG

Meeting

3rd ECRIT

WG Meeting

IETF#64

IETF#65 IETF#66

IETF ECRIT –

3GPP Workshop

1st SDO Emergency

Services Workshop

2nd SDO Emergency

Services Workshop

IETF#67 IETF#68

IETF ECRIT – IEEE

Workshop

7th ECRIT WG

Meeting

6th ECRIT WG

Meeting8th ECRIT

WG Meeting

3nd SDO Emergency

Services 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 D2008 2007

9th ECRIT WG

Meeting

IETF#71 IETF#72

4th SDO Emergency

Services Workshop

5th SDO Emergency

Services Workshop

IETF#73

10th ECRIT WG

Meeting

11th ECRIT WG

Meeting