Emergency Service Identifiers draft-ietf-sipping-sos-01 draft-schulzrinne-sipping-service-01

1
Emergency Service Identifiersdraft-ietf-sipping-s
os-01draft-schulzrinne-sipping-service-01

• Henning Schulzrinne
• Columbia University
• hgs_at_cs.columbia.edu

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

4
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

5
Options

• Numbers (tel911context1)
• about 60, some used for non-emergency use
• telsos
• not a real tel URI
• requires universal deployment
• SIP URL parameter sipexample.comusersos
• not backwards compatible
• not really a user
• Special domain sipfire_at_sos.int
• valid URL
• needs support infrastructure (DNS, proxy) for
  that domain

• SIP user sipsos_at_example.com
• 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 email
• a service URN (see later)
• avoids confusion and overloading
• works for protocols other than SIP
• needs more UAC changes

6
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
• sipsos_at_(anything) or sipssos_at_(anything)
• If so, handle as emergency call
• e.g., if URI is sipsos_at_(anything), 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 sipsos_at_sos-service-provider.c
  om

7
Media tag for emergency services

• SIP caller preferences model (RFC 3840/3841)
• Motivation Avoid adding lots of services to URI
• instead of sipsos.fire_at_example.com
• Disadvantage requires UA support
• Accept-Contact sip.emergency-service"sos.marin
  e
• Open issue helpful enough?

8
SIP request
9-1-1
INVITE sipfire_at_paris.ia.state.us To
urnservicesos 123 Main, Paris, IA
INVITE urnservicesos To urnservicesos 123
Main, Paris, IA
9
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

10
URN structure

• urnservicesname.subsname
• urnservicesname reaches any service of type
  sname
• Examples
• urnservicesos
• urnservicesos.fire
• urnservicesos.police
• urnservicesos.marine
• urnservicesos.mountain
• urnservicesos.rescue
• urnservicesos.poison
• urnservicesos.suicide
• urnservicesos.mental-health

11
UAC requirements

• Todays hard phones with numeric dialing only
• BCP proxies SHOULD recognize 911, 112 and
  geographically local numbers as (e.g.,)
  sip911_at_local-domainuserphone
• 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

12
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

13
Suggested path forward

• Allow both approaches
• allow backward compatibility now
• more general architecture and extensibility later
• UAC should try urnservice first
• On failure (404 response), fall back to sipsos_at_