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

Slides:



Advertisements
Similar presentations
Communication Service Identifier Requirements on SIP draft-loreto-3gpp-ics-requirements.txt
Advertisements

Emergency Services Chitra S VOIP Security Fall 2008.
Doc.: IEEE /0115r0 Submissions January 2008 Gabor Bajko, NokiaSlide 1 Support for un-authenticated Emergency Services Date: Authors:
ECRIT Virtual Interim Meeting 26th February, 2PM EST Marc Linsner Hannes Tschofenig.
1 5 th SDO Emergency Services Workshop October 2008 “sos” URI parameter for marking emergency requests Milan Patel 5 th SDO Emergency Services Workshop.
IETF ECRIT update Marc Linsner 5/11/10. ECRIT Charter (or a piece of it) ………The group will show how the availability of location data and call routing.
1 Improved DNS Server Selection for Multi-Homed Nodes draft-savolainen-mif-dns-server-selection-04 Teemu Savolainen (Nokia) Jun-ya Kato (NTT) MIF WG meeting.
Origins of ECRIT IETF has been working on location since 2000 –Spatial BoF, eventually GEOPRIV chartered in 2001 GEOPRIV provides location information.
Emergency Services IAB Tech Chat 28 th February 2007 Hannes Tschofenig.
An Engineering Approach to Computer Networking
July 2006IETF66 - ECRIT1 RELO: Retrieving End System Location Information draft-schulzrinne-geopriv-relo-00 Henning Schulzrinne.
Internet Real-Time Lab, Columbia University Emergency Calling for VoIP Wonsang Song, Jong Yul Kim, and Henning Schulzrinne.
SDO Emergency Services Coordination Workshop (ESW06) 1 Emergency Service Identifiers Presented by Henning Schulzrinne Columbia University
An SAIC Company Telcordia View of NENA Progress on VoIP Migration Plan Telcordia Contacts: Nadine Abbott (732) An SAIC Company.
March 2006IETF65 - ECRIT1 Emergency Service Identifiers draft-ietf-ecrit-service-urn-01 Henning Schulzrinne Columbia University
IEEE Emergency Services DCN: Title: call flow for Layer 2 support for unauthenticated requests Date.
Ernst Langmantel Technical Director, Austrian Regulatory Authority for Broadcasting and Telecommunication (RTR GmbH) The opinions expressed in this presentation.
November 2006IETF67 - ECRIT1 A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure draft-polk-ecrit-dhc-lost-discovery-01.
SDO Emergency Services Coordination Workshop (ESW06) 1 A Location-to-Service Translation Protocol (LoST) & Mapping Protocol Architecture Ted Hardie Andrew.
IT 210 The Internet & World Wide Web introduction.
Doc.: IEEE /0033r2 IMS Emergency Call Requirements January 2007 Donghee ShimSlide 1 IMS Emergency Call Requirements & Emergency Call number support.
NENA Next Generation Architecture
1 NGN Issues - Numbering and Addressing Peter Darling ACIF NGN FOG No. 3.
DNS (Domain Name System) Protocol On the Internet, the DNS associates various sorts of information with domain names. A domain name is a meaningful and.
Status and Development of VoIP based emergency calls Alexander Mayrhofer, nic.at GmbH The 1st European Security and Safety Summit Brussels, June 2007.
Session Initiation Protocol (SIP). What is SIP? An application-layer protocol A control (signaling) protocol.
1 AutoconfBOF2.PPT / Aug / Singh,Perkins,Clausen IETF Not Confidential Ad hoc network autoconfiguration: definition and problem statement (draft-singh-autoconf-adp-00.txt)
Draft-rosen-ecrit-emergency- framework-00 Brian Rosen NeuStar CPa
IETF – ECRIT Emergency Context Resolution using Internet Technologies ESW 5 – Vienna October 2008 Marc Linsner.
Jun Li DHCP Option for Access Network Information draft-lijun-dhc-clf-nass-option-01.
Draft-polk-ecrit-mapping-events-00 James Polk March 21 st, 2006.
CP-a Emergency call stage 2 requirements - A presentation of the requirements from 3GPP TS Keith Drage.
November 2005IETF64 - ECRIT1 Emergency Service Identifiers draft-ietf-sipping-sos-01 draft-schulzrinne-sipping-service-01 Henning Schulzrinne Columbia.
IETF GEOPRIV Status Richard L. Barnes BBN Technologies GEOPRIV Secretary Emergency Services Workshop October 2008.
July 2006IETF66 - ECRIT1 LoST: A Location-to-Service Translation Protocol draft-ietf-ecrit-lost-00 Ted Hardie Andrew Newton Henning Schulzrinne Hannes.
ECRIT Virtual Interim Meeting 3rd June 2009, 1PM EDT (New York) Marc Linsner Hannes Tschofenig.
Considerations for Civic Addresses in PIDF-LO draft-wolf-civicaddresses-austria-01 IETF 71, Mar 2008, Philadelphia, PA, USA Karl Heinz Wolf Alexander Mayrhofer.
Andrew Allen Communication Service Identifier.
Core VoIP and 911 issues and alternatives Henning Schulzrinne Columbia University August 2003.
1 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Company Confidential Conveying Policy URI in Call-info purpose Hisham Khartabil Aki Niemi SIP WG.
ECRIT - Getting Certain URIs, and Alternatives to Getting Emergency Dialstring(s) draft-polk-ecrit-lost-server-uri-00 draft-polk-dhc-ecrit-uri-psap-esrp-00.
LoST A Location-to-Service Translation Protocol draft-hardie-ecrit-lost-00.txt.
Protecting First-Level Responder Resources in an IP-based Emergency Services Architecture 13 th April 2007, THE FIRST INTERNATIONAL WORKSHOP ON RESEARCH.
1 3gpp_trans/ / IPv6 Transition Solutions for 3GPP Networks draft-wiljakka-3gpp-ipv6-transition-00.txt Juha Wiljakka,
ECRIT requirements update draft-schulzrinne-ecrit-requirements-01 IETF 63 Aug 02, 2005 Roger Marshall
March 20th, 2001 SIP WG meeting 50th IETF SIP WG meeting Overlap signalling handling
Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices draft-ietf-ecrit-unauthenticated-access-03.txt.
November 2005IETF64 - SIPPING1 Service Identifiers draft-schulzrinne-sipping-service-01 Henning Schulzrinne Columbia University
© 2015 Airbus DS Communications, Inc. All rights reserved. Lights, Camera, NG9-1-1 Diana Gijselaers/ Solutions Engineer – NG9-1-1 GIS and Core Services.
Emergency Context Resolution with Internet Technologies (ecrit) Hannes Tschofenig, Marc Linsner IETF 66, Montreal, June 2006.
ECRIT - IETF 62 (March 2005) - Minneapolis 1 Requirements for Emergency Calling draft-schulzrinne-sipping-emergency-req-01 draft-ietf-sipping-sos-01 Henning.
Emergency Context Resolution with Internet Technologies (ECRIT) Chairs: Marc Linsner & Roger Marshall Standing In for the Chairs: Brian Rosen IETF 94.
THIS IS THE WAY ENUM Variants Jim McEachern
Emergency Context Resolution with Internet Technologies Marc Linsner Roger Marshall IETF 86 Orlando March 13, 2013.
ALTO Protocol draft-ietf-alto-protocol-14
RELO: Retrieving End System Location Information draft-schulzrinne-geopriv-relo-03 Henning Schulzrinne March 2007 IETF68 - GEOPRIV.
draft-rosen-nena-ecrit-requirements Brian Rosen
draft-ietf-geopriv-lbyr-requirements-02 status update
Emergency Service Identifiers draft-ietf-ecrit-service-urn-01
Next Generation Project
Phase 4 : Call Presentation Four Phases of Emergency Calling
RELO: Retrieving End System Location Information draft-schulzrinne-geopriv-relo-03 Henning Schulzrinne March 2007 IETF68 - GEOPRIV.
Ted Hardie Andrew Newton Henning Schulzrinne Hannes Tschofenig
IMS Emergency Call Requirements & Emergency Call number support
Protocol Details from 3GPP TS
An Engineering Approach to Computer Networking
IMS Emergency Call Requirements & Emergency Call number support
SHAKEN for Presented to: Ericsson Contact:
Trustworthy Location ECRIT WG IETF 80 Tuesday, March 29, 2011
MIF DHCPv6 Route Option Update
Presentation transcript:

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

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