1. 1 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Emergency calls related work done in IETF Gabor Bajko May 22, 2006

2. 2 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials The Issues Component Issues How to identify that the call is for emergency service How to discover the locally significant emergency identifiers How to determine caller location How to represent the location How to route the call to the correct destination based on caller location How to carry location within the signaling How to indicate priority and what is it used for Architectural Issues Who does each of the steps above Meta Issues How to verify the authenticity/integrity of caller location How to treat the caller authentication (or the lack of it)

3. 3 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials IETF Work Organization Signaling Protocol Agnostic Items How to identify that the call is for emergency service  ECRIT WG How to discover the locally significant emergency identifiers  ECRIT WG problem space (protocols done elsewhere, e.g. DHC WG, SIPPING WG) How to determine caller location  GEOPRIV WG problem space (protocols done in various places, e.g. in DHC WG, IEEE, 3GPP, …) How to represent the location  GEOPRIV WG How to route the call to the correct destination based on caller location  ECRIT WG Signaling Protocol Specific Items How to carry location within the signaling  SIPPING WG (for SIP) How to indicate priority and what is it used for  SIP WG (for SIP)

4. 4 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Service URN Current draft: draft-ietf-ecrit-service-urn-03.txt. Recently put in WGLC It defines the “service” URN namespace with sub-services These URNs are supposed to be protocol elements and not text describing the service (and not necessarily shown to the user) There are a number of sub-services defined under the URN:service:sos, with global meaning. The terminal would probably need to have an interpreter which recognises the services provided in that network and displays e.g. the icon and/or the name of it in the user’s language on the GUI. Service URNs are NOT routable, they need to be translated into routable addresses It is hierarchical: If "URN:service:" 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid service URNs. If the queried service ‘x.y.z’ does not exists, the resolution for ‘x.y’ or eventually ‘x’ could be returned as a matching result The client would do the query well before emergency is needed, and keep the info up-to-date in terminals’ cache.

5. 5 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Service URN - cont Example service URNs proposed by the draft to be registered: urn:service:sos – this is proposed to be the default one 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 urn:service:sos.suicide urn:service:counseling urn:service:counseling.mental-health urn:service:counseling.children

6. 6 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials LoST (draft-hardie-ecrit-lost-00.txt) LoST: Location-to- Service Translation Protocol (name might change) It is an early draft, many details still missing XML-based protocol for mapping service identifiers and geospatial or civic location information (PIDF-LO) to service contact URIs (carrying protocol to be chosen) It requires the client to know the address of the LoST server. The ultimate goal is that the LoST server provides the client with a concrete address to contact (which could be a service contact URI –PSAP URI-, a tel. number, IP address, etc.) It recommends that when the LoST server is contacted and the requested service does not exist, then the resolution of the more specific service is returned (on the e- mail exploder it was suggested that in this case the service URN itself to be returned too). E.g.: in case urn:service:sos.fire does not exists, the address of the server hosting urn:service:sos would be returned. Finding LoST server address: A new S-NSPTR application service tag is defined: SURN; and a new label is registered: “SURN.sos”E.g.: the S-NAPTR query is made to SURN.sos:LoST (and this would return a result containing the URI to contact using LoST protocol for emergency services)  all this to find the LoST server (adv: dynamic, DDDS could be used)

7. 7 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Location – GEOPRIV WG How to determine caller location DHCP for coordinate based location: RFC 3825 DHCP for civic location: draft-ietf-geopriv-dhcp-civil (in RFC Editor Queue) A separate query protocol (based on IP address): draft-linsner-geopriv- lcp A similar HTTP-based protocol: draft-winterbottom-geopriv-held-sighting Location can be provided by value or by reference draft-winterbottom-location-uri How to represent location PIDF-LO: RFC 4119 Several drafts now on PIDF-LO usages and clarifications

8. 8 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Questions How would a roaming user find out what kind of emergency sub-services (e.g. sos.poison) are supported by the network it just attached to (or country it just roamed to)? How to download the list of these sub-services? How could this situation be handled: A european comes to US and dials 112 instead of 911

9. 9 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Steps to be performed with LoST After attachment the terminal should somehow find out the emergency services available in the network it attached to (how??) It stores the services in the cache When needed, it picks up the emergency service type it needs and makes an S-NAPTR query to find a server to contact (LoST server) Using LoST protocol, it provides the emergency service URN and its location info to get a resolution (the nearest PSAP hosting that service) Contact the PSAP returned in response using the protocol specified

10. 10 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Ecrit work usage in MMD – possible solution In 3GPP: when the client places an emergency call, the P-CSCF has to identify it as an emergency (tbd how)  possible solution: put the service URN somewhere into the SIP request??? And let the P-CSCF detect it OR rather let the client to do a NAPTR query using the emergency URN and then send the SIP request to the address returned. P-CSCF would need to know the emergency URIs from NAPTR in order to detect emergency In 3GPP: Once P-CSCF identified the call as emergency, routes it to an E- CSCF In 3GPP: E-CSCF determines the closest PSAP using the client’s location information by querying a database (tbd how)  possible solution: LoST protocol could be used by the E-CSCF to query a LoST server and find out the closest PSAP hosting the required emergency service E-CSCF could be preconfigured or use DHCP for LoST server address Service URN resolution to routable URI would not be needed by the client, the E-CSCF could do it If there is no direct match, E-CSCF could do a best guess, user would not be involved