1 / 11

Emergency Service Identifiers

Emergency Service Identifiers. Presented by Henning Schulzrinne Columbia University hgs@cs.columbia.edu. Service URN. Idea: Identifiers to denote emergency calls and other generic (communication) services Described in draft-ietf-ecrit-service-urn-05.txt (passed WGLC; sent to the IESG)

abanister
Télécharger la présentation

Emergency Service Identifiers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Emergency Service Identifiers Presented by Henning Schulzrinne Columbia University hgs@cs.columbia.edu SDO Emergency Services Coordination Workshop (ESW06) 

  2. Service URN • Idea: Identifiers to denote emergency calls • and other generic (communication) services • Described in draft-ietf-ecrit-service-urn-05.txt (passed WGLC; sent to the IESG) • Document defines the following emergency service identifiers: sos General emergency services sos.animal-control Animal control sos.fire Fire service sos.gas Gas leaks and gas emergencies sos.marine Maritime search and rescue sos.mountain Mountain rescue sos.physician Physician referral service sos.poison Poison control center sos.police Police, law enforcement SDO Emergency Services Coordination Workshop (ESW06) 

  3. ‘counseling’ services SDO Emergency Services Coordination Workshop (ESW06) 

  4. Services under discussion • “211” (social service referral), “311” (non-emergency government services) • Emergency services (first responders) • used by PSAP, not civilians • e.g., urn:service:es:police • Non-emergency commercial services • urn:service:restaurant.italian • urn:service:transportation.taxi SDO Emergency Services Coordination Workshop (ESW06) 

  5. UA recognition & UA resolution location information mapping mapping may recurse DHCP LLDP-MED 9-1-1 (dial string) leonianj.gov INVITE urn:service:sos To: urn:service:sos Route: sip:fire@leonianj.gov <location> INVITE urn:service:sos To: urn:service:sos Route: sip:psap@leonianj.gov <location> identification TBD SDO Emergency Services Coordination Workshop (ESW06) 

  6. UA recognition & proxy resolution mapping 9-1-1 (outbound proxy) provider.com INVITE urn:service:sos To: urn:service:sos <location> INVITE urn:service:sos To: urn:service:sos Route: sip:psap@leonianj.gov <location> SDO Emergency Services Coordination Workshop (ESW06) 

  7. UA recognition & proxy resolution(proxy location determination) mapping 9-1-1 provider.com INVITE sip:psap@leonianj.gov To: urn:service:sos Geolocation: <location> INVITE urn:service:sos To: urn:service:sos SDO Emergency Services Coordination Workshop (ESW06) 

  8. Proxy recognition & proxy resolution mapping 9-1-1 provider.com INVITE urn:service:sos To: sip:911@provider.com;user=phone Geolocation: <location> Route: sip:psap@leonianj.gov INVITE sip:911@provider.com;user=phone To: sip:911@provider.com;user=phone SDO Emergency Services Coordination Workshop (ESW06) 

  9. Labeling requirements • Needs to work even if UAC does not recognize emergency call • Needs to survice multiple mappings • e.g., country  state  county • Needs to play nice with SIP routing architecture • e.g., pre-loaded service routes SDO Emergency Services Coordination Workshop (ESW06) 

  10. only trust Accept-Contact from same trust domain see P-Asserted-Identity model (RFC 3325)  brittle or use Identity model  signed by outbound proxy unfortunately, not covered by doesn’t help with UA rec/res model! creating a new header likely to have similar issues re-do mapping and ensure that URL matches server can learn list of “legal” URLs after a while can fail if mapping is dynamic (advertisement changes) then just replaces URL forces each outbound proxy to do mapping check external source that URL is indeed a PSAP use draft-ietf-sipping-certs for destination URL, but would need to have a role-based cert “this is a bona-fide PSAP” easy to posit, harder to deploy globally can incur significant delay but only needed when there’s service differentiation new TLD for PSAPs only  Alternatives considered SDO Emergency Services Coordination Workshop (ESW06) 

  11. References and contact info • IETF ECRIT Working Group http://www.ietf.org/html.charters/ecrit-charter.html • Service URN IETF Draft http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-service-urn/ SDO Emergency Services Coordination Workshop (ESW06) 

More Related