1. Standardizing IP-based Emergency Services Richard Barnes BBN Technologies IETF GEOPRIV Chair rbarnes@bbn.com Hannes Tschofenig Nokia-Siemens IETF ECRIT Chair Hannes.tschofenig@gmx.net

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

3. 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”.

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

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

6. 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/08- 001_20051205.pdf http://www.nena.org/media/File/08- 001_20051205.pdf – Other national variants (often derived from the NENA i2 work exist)

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

8. NENA/EENA 3GPP, 3GPP2, Wimax Forum IETF

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

10. PSAP / Call Taker Subscriber Database VSP (2) Query for location VoIP Call (1)(5) dial 1-1-2 Today’s VoIP Emergency Service SIP Proxy User VoIP Call (0) Enter Location (3) Location Info

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

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

13. PSAP / Call Taker Routing Database VSP (2)Location Location + Service Identifier (3) PSAP URI (4) INVITE Request URI: 112 To: 112 (1)(5) dial 1-1-2 “Legacy End Points” Location Information Server 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 INVITE Request URI: urn:service:sos To: 112 Route Header: PSAP URI SIP Proxy

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

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

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

17. PSAP / Call Taker (2)Location Location + Service Identifier (3) PSAP URI (4) (1)(5) Initial Upgrades to End Hosts Location Information Server INVITE Request URI: urn:service:sos To: urn:service:sos INVITE Request URI: urn:service:sos To: urn:service:sos Route Header: PSAP URI dial 1-2-2 Routing Database VSP SIP Proxy (0) Access Network Identifier or LbyR

18. Assumptions End host detects emergency call (based on some pre- configured 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-geopriv- lis-discovery-11) and may be able to obtain a LbyR via http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-dhcp- lbyr-uri-option/ or http://tools.ietf.org/wg/geopriv/draft- ietf-geopriv-http-location-delivery/.http://tools.ietf.org/html/draft-ietf-geopriv- lis-discovery-11 http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-dhcp- lbyr-uri-option/http://tools.ietf.org/wg/geopriv/draft- ietf-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.

19. Fully Upgraded End Device 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. Routing Database PSAP (1)Location Location + Service Identifier (2) PSAP URI + emergency number (3) (4) (5) Location Information Server INVITE Request URI: urn:service:sos To: urn:service:sos Route Header: PSAP URI INVITE Request URI: urn:service:sos To: urn:service:sos Route Header: PSAP URI dial 1-2-2 (Note: This is a random IP device.) (1)GPS Info VSP SIP Proxy

20. 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).

21. … 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.

22. Identifying an Emergency Call

23. Emergency Numbers Emergency Numbers used worldwide, see http://www.sccfd.org/travel.htmlhttp://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

24. 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.htmlhttp://www.ietf.org/html.charters/ecrit-charter.html Service URN registry established in http://tools.ietf.org/html/rfc5031 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

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

26. Location

27. Encoding of Location Information – The GEOPRIV WG http://www.ietf.org/html.charters/geopriv- charter.html uses two formats for location information encoding.http://www.ietf.org/html.charters/geopriv- charter.html 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), or simply PIDF-LO. – PIDF-LO uses the Geography Markup Language (GML) developed by OGC for describing geodetic information.

28. 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: Element – Encapsulates location information – GML 3.0 schema (mandatory-to-implement) – Supports civic location format (optional-to-implement) Element – Describes the way location information was derived or discovered. – Example: gps – Registry available at: http://www.iana.org/assignments/method-tokenshttp://www.iana.org/assignments/method-tokens Element – Entity or organization that supplied this location information Element – Used to indicate privacy preferences

29. Example: PIDF-LO with Geodetic Info <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"> -43.5723 153.21760 802.11 www.example.com no 2003-06-23T04:57:29Z https://www.example.com/myrules These are my privacy rules 2007-06-22T20:57:29Z mac:8asd7d7d70cf

30. Example: PIDF-LO with Civic Info <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"> US New York Broadway 123 Suite 75 10027-0401 2007-06-22T20:57:29Z mac:8asd7d7d70cf

31. More on Civic Information – Initially civic location was specified for DHCP in RFC 4776* (http://www.ietf.org/rfc/rfc4776.txt)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.http://www.ietf.org/rfc/rfc5139.txt – 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-ietf- geopriv-civic-address-recommendationshttp://tools.ietf.org/html/draft-ietf- geopriv-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.

32. RFC 4119 Civic Location Info LabelDescriptionExample countryThe country is identified by the two- letter ISO 3166 code US A1national subdivisions (state, region, province, prefecture) New York A2county, parish, gun (JP), district (IN)King's County A3city, township, shi (JP)New York A4city division, borough, city district, ward, chou (JP) Manhattan A5Neighbourhood, blockMorningside Heights A6StreetBroadway PRDLeading street directionN, W PODTrailing street suffixSW

33. RFC 4119 Civic Location Info, cont. LabelDescriptionExample STSStreet suffixAvenue, platz, Street HNOHouse number, numeric part only123 HNSHouse number suffixA, ½ LMKLandmark or vanity addressLow Library LOCAdditional location informationRoom 543 FLRFloor5 NAMName (residence, business or office occupant ) Joe’s Barbershop PCPostal code10027-0401

34. RFC 5139 Civic Location Info LabelDescriptionExample BLDBuilding (structure)Hope Theatre UNITUnit (apartment, suite)12a ROOMRoom450F PLCPlace-TypeOffice PCNPostal community nameLeonia POBOXPost office Box (P.O. Box)U40 ADDCODEAdditional Code13203000003 SEATSeat (desk, cubicle, workstation)WS 181 RDPrimary road or streetBroadway RDSECRoad section14 RDBRRoad branchLane 7 RDSUBBRRoad sub-branchAlley 8 PRMRoad pre-modifierOld POMRoad post-modifierExtended

35. 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/rfc5491http://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.

36. 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 http://tinyurl.com/6qdbxt 4) Location Server from 3 rd Party Providers using Global Cell-ID database, BSSID database Obtaining Location Information

37. 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. 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 Location Information Server Request Location Location Target

38. LCPs, cont. Link layer mechanisms (e.g., various extensions to IEEE link layer protocols) LLDP-MED – http://tinyurl.com/5eqlpq http://tinyurl.com/5eqlpq – http://tinyurl.com/5o3yxk http://tinyurl.com/5o3yxk – http://tinyurl.com/6hvag5 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 http://tinyurl.com/6oj52t http://www.ietf.org/rfc/rfc4776.txt – RFC 3825 for geodetic location information (slides at http://tinyurl.com/6jgchf) 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 ) http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery OMA MLS/SUPL : http://tinyurl.com/6qdbxt http://tinyurl.com/6qdbxt

39. 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 civic geodetic Request civic location informationRequest geodetic location info Request for location information (no restrictions)

40. 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 <Point xmlns="http://www.opengis.net/gml" srsName="urn:ogc:def:crs:EPSG::4326"> -34.407 150.88001 2006-01-11T03:42:28+00:00 2006-01-10T03:42:28+00:00

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

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

43. LbyR Example Request <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> locationURI

44. LbyR Example Response <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" code="success" message="OK"> https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o sips:9769+357yc6s64ceyoiuy5ax3o@ls.example.com

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

46. (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 INVITE Request URI: urn:service:sos To: urn:service:sos INVITE Request URI: urn:service:sos To: urn:service:sos Route Header: PSAP URI (2b) Location VSP SIP Proxy IAP LIS (2a) Request location for VCI/VPI xyz. (2b) Location

47. 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 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) De-Referencing

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

49. Emergency Call Routing

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

51. Features Protocol specification available with – http://tools.ietf.org/html/rfc5222 http://tools.ietf.org/html/rfc5222 Satisfies the requirements for mapping protocols: – http://tools.ietf.org/html/rfc5012 http://tools.ietf.org/html/rfc5012 Provides civic address validation – Returns XML tag names of components (classified into, and ) 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 )http://tools.ietf.org/html/rfc5139

52. LoST Example Query with geodetic location info <findService xmlns="urn:ietf:params:xml:ns:lost1" xmlns:p2="http://www.opengis.net/gml" serviceBoundary="value" recursive="true"> 37.775 -122.422 urn:service:sos.police

53. LoST Example: Response <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"> New York City Police Department urn:service:sos.police 37.775 -122.4194 … 37.775 -122.4194 sip:nypd@example.com xmpp:nypd@example.com 911

54. LoST Example Query with civic location <findService xmlns="urn:ietf:params:xml:ns:lost1" recursive="true" serviceBoundary="value"> <civicAddress xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> Germany Bavaria Munich Otto-Hahn-Ring 6 81675 urn:service:sos.police

55. Example: Location Validation <findService xmlns="urn:ietf:params:xml:ns:lost1" recursive="true" validateLocation="true" serviceBoundary="value"> <civicAddress xmlns= "urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> DE Bavaria Munich Otto-Hahn-Ring 6 81675 urn:service:sos.police <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"> … country A1 A3 A6 PC HNO … Request Response (XML fragment)

56. Example: listServices and listServicesResponse <listServices xmlns="urn:ietf:params:xml:ns:lost1"> urn:service:sos <listServicesResponse xmlns="urn:ietf:params:xml:ns:lost1"> 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 Request Response is a variation of that includes location in the query.

57. 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 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 http://tinyurl.com/63dvs4 There are multiple ways to deploy LoST. LoST deployment needs country- specific 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? From a Protocol to an Architecture

58. 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)http://tools.ietf.org/html/rfc5222 – Via DHCP (defined in http://tools.ietf.org/html/rfc5223)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 http://www.tschofenig.priv.at/wp/?p=486

59. T3 (.at) Terminology T1 (.us) T2 (.de) FG Resolver seeker Forest Guide Tree Node Tree Node Leaf Node Leaf Node Leaf Node Leaf Node

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

61. Example T1 (.us) T2 (.de) T3 (.at) FG broadcast (gossip) T1:.us T2:.de resolver seeker 313 Westview Leonia, NJ US

62. 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 ….

63. Standardization of the emergency call procedures for SIP.

64. 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-framework/ – http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-phonebcp/ 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/draft- ietf-sip-location-conveyance/ as protocol mechanisms. draft-ietf-ecrit-phonebcphttp://tools.ietf.org/wg/sip/draft- ietf-sip-location-conveyance/

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

66. Mechanism to carry location by value and by reference in SIP http://tools.ietf.org/html/draft-ietf-sip-location-conveyance 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

67. 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.0 Via: SIP/2.0/TCP pc33.atlanta.example.com ;branch=z9hG4bK77i832k9 Max-Forwards: 70 To: Bob From: Alice ; tag=1928301774 Call-ID: a84b4c76e6Kr456@pc33.atlanta.com Geolocation: cid:alice123@atlanta.example.com;cid:alice123@atlanta.example.com inserted-by=alice@atlanta.example.com; recipient=endpoint Supported: geolocation CSeq: 314159 INVITE Contact: Accept: application/sdp, application/pidf-xml Content-Type: multipart/mixed; boundary=0a0 Content-Length: 543 INVITE geolocation (if as a message body) sdp

68. --0a0 Content-Type: application/pidf+xml Content-ID: cid:alice123@atlanta.example.com ….. 36.132N 115.151W ….. 802.11 www.example.com ….. --0a0-- Alice Example: SIP Invite with Location by Value (2) Bob INVITE XML fragment of multipart MIME body Example geodetic location

69. Alice Example: SIP Invite with Location by Value (3) Bob INVITE --0a0 Content-Type: application/pidf+xml Content-ID: cid:alice123@atlanta.example.com... US Nevada Las Vegas 399 Convention Center Drive 89109 LVCC 110... --0a0-- XML fragment of multipart MIME body Example civic location

70. Alice Example: SIP Invite with Location by Reference (1) Bob 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 From: Alice ; 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: Accept: application/sdp, application/pidf-xml Content-Type: application/sdp Content-Length: 243 INVITE Example shows location added by value. sips:alice123@atlanta.exampl e.com represents the location by reference

71. 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 OK Via: SIP/2.0/TCP sip:alice@atlanta.com ;branch=z9hG4bK77i832k9 To: Bob ; tag=a6c85e3 From: Alice ;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…) INVITE Example: SIP Invite with Location by Reference (2)

72. 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/ 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 http://tools.ietf.org/html/draft-barnes-ecrit-rough-loc

73. Unauthenticated Emergency Services Reference: http://tools.ietf.org/id/draft-schulzrinne-ecrit- unauthenticated-accesshttp://tools.ietf.org/id/draft-schulzrinne-ecrit- unauthenticated-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.

74. 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-ecrit- psap-callbackhttp://tools.ietf.org/id/draft-schulzrinne-ecrit- psap-callback

75. A few words about other organizations

76. 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 NG9- 1-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.http://www.nena.org NENA

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

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

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

80. i3 Functional Architecture

81. EENA NG112 TC EENA: http://www.eena.orghttp://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)!

82. 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 TechnicalOperationsEducation Partnership The EENA NG112 Project – Long Term View Transition

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

84. How to contribute? Send a mail to Gary (gm@eena.org), Roger (rhixson@nena.org) or myself (Hannes.Tschofenig@gmx.net).gm@eena.orgrhixson@nena.orgHannes.Tschofenig@gmx.net – 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.

85. 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 serviceshttps://lists.cs.columbia.edu/cucslists/listinfo/es-coordination – 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 http://www.emergency-services-coordination.info Next workshop to be in March/April 2010, in US or Europe

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

87. 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.) http://www.ietf.org/html.charters/ecrit-charter.html Contribute your research results