November 2005IETF64 - ECRIT1 Emergency Service Identifiers draft-ietf-sipping-sos-01 draft-schulzrinne-sipping-service-01 Henning Schulzrinne Columbia University

November 2005IETF64 - ECRIT2 Motivation If resolution done by proxy, needs to identify call needing resolution May pass outbound proxy Also, needed for subsequent proxies Context-dependent resolution –context = location for now ECRIT mapping protocol SIP

November 2005IETF64 - ECRIT3 SIP mechanisms available To header = “logical destination” –not rewritten by proxies –not touched by SBCs Request-URI = current destination –may be rewritten by proxies SIP header fields –copied by proxies, but maybe not SBCs

November 2005IETF64 - ECRIT4 Requirements Direct user interface, without “dialing” number –but do NOT require user to input this identifier directly –i.e., separate user interface from protocol identifier! Reach emergency help in any country, without knowledge of local numbers –also, universally recognizable by proxies regardless of location of caller Deployable incrementally –even if not all entities support the mechanism Testable without impacting PSAP (human) resources Backwards-compatible with PSTN emergency calling

November 2005IETF64 - ECRIT5 Options Numbers (tel:911;context=+1): –about 60, some used for non- emergency use tel:sos –not a “real” tel URI –requires universal deployment SIP URL parameter: sip:example.com;user=sos –not backwards compatible –not really a user Special domain: –valid URL –needs support infrastructure (DNS, proxy) for that domain SIP user: –backward compatible –only needs home proxy to work –violates proxy behavior rules: non- domain proxy may attempt mapping –overloads user name but postmaster/webmaster has worked pretty well for a service URN (see later) –avoids confusion and overloading –works for protocols other than SIP –needs more UAC changes

November 2005IETF64 - ECRIT6 ‘sos’ URL Similar in spirit to RFC 2142 (“postmaster”) –related to RFC 3087 (“Control of Service Context using SIP Request-URI”) Any proxy receiving a SIP request checks whether “To” URL has format or If so, handle as emergency call –e.g., if URI is invoke mapping protocol to get PSAP URI If all else fails, home proxy will recognize it –  testable, incrementally deployable –can also create special service domains just for emergency services:

November 2005IETF64 - ECRIT7 Media tag for emergency services SIP caller preferences model (RFC 3840/3841) Motivation: Avoid adding lots of services to URI –instead of Disadvantage: requires UA support Accept-Contact: *;sip.emergency-service="sos.marine” Open issue: helpful enough?

November 2005IETF64 - ECRIT8 SIP request INVITE urn:service:sos To: urn:service:sos 123 Main, Paris, IA INVITE To: urn:service:sos 123 Main, Paris, IA 9-1-1

November 2005IETF64 - ECRIT9 Why a URN? Identifies a generic service, not a specific resource Uses mapping protocol: –{identifier, location}  URL(s) Can be used anywhere a URN/URL is allowed, e.g.: –web pages –result returned by mapping protocol –request and To URI in SIP

November 2005IETF64 - ECRIT10 URN structure urn:service:sname.subsname… urn:service:sname reaches any service of type ‘sname’ Examples: –urn:service:sos –urn:service:sos.fire –urn:service:sos.police –urn:service:sos.marine –urn:service:sos.mountain –urn:service:sos.rescue –urn:service:sos.poison –urn:service:sos.suicide –urn:service:sos.mental-health

November 2005IETF64 - ECRIT11 UAC requirements Today’s hard phones with numeric dialing only: –BCP: “proxies SHOULD recognize 911, 112 and geographically local numbers as (e.g.,) sos URL: –needs to be able to emit alphanumeric SIP URL, not just phone number URLs service URN: –needs to recognize emergency number and emit service URN

November 2005IETF64 - ECRIT12 Proxy requirements SOS URL –at least one proxy from caller to URL domain needs to understand convention not necessarily outbound proxy service URN –resolution by proxy  first proxy contacted by UAC –end system does ECRIT mapping  inserts PSAP URL into request-URI, service URN into “To” header  no proxy support

November 2005IETF64 - ECRIT13 Suggested path forward Allow both approaches –allow backward compatibility now –more general architecture and extensibility later UAC should try urn:service first On failure (404 response), fall back to