1 / 10

Emergency Service Identifiers draft-ietf-ecrit-service-urn-01

Emergency Service Identifiers draft-ietf-ecrit-service-urn-01. Henning Schulzrinne Columbia University hgs@cs.columbia.edu. Open Issues. Identifying the call post-resolution Server resolution. UA recognition & UA resolution. location information. mapping. mapping may recurse. DHCP

mada
Télécharger la présentation

Emergency Service Identifiers draft-ietf-ecrit-service-urn-01

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 Identifiersdraft-ietf-ecrit-service-urn-01 Henning Schulzrinne Columbia University hgs@cs.columbia.edu IETF65 - ECRIT

  2. Open Issues • Identifying the call post-resolution • Server resolution IETF65 - ECRIT

  3. UA recognition & UA resolution location information mapping mapping may recurse DHCP LLDP-MED 9-1-1 (dial string) leonianj.gov INVITE sip:psap@leonianj.gov To: urn:service:sos Accept-Contact: *;sip.service="urn:service:sos" <location> INVITE sip:psap@leonianj.gov To: urn:service:sos Accept-Contact: *;sip.service="urn:service:sos" <location> IETF65 - ECRIT

  4. UA recognition & proxy resolution mapping 9-1-1 provider.com INVITE urn:service:sos To: urn:service:sos Accept-Contact: *;sip.service="urn:service:sos" <location> INVITE sip:psap@leonianj.gov To: urn:service:sos Accept-Contact: *;sip.service="urn:service:sos" <location> IETF65 - ECRIT

  5. UA recognition & proxy resolution(proxy location determination) mapping 9-1-1 provider.com INVITE sip:psap@leonianj.gov To: urn:service:sos Location: <location> Accept-Contact: *;sip.service="urn:service:sos" INVITE urn:service:sos To: urn:service:sos Accept-Contact: *;sip.service="urn:service:sos" IETF65 - ECRIT

  6. Proxy recognition & proxy resolution mapping 9-1-1 provider.com INVITE sip:psap@leonianj.gov To: sip:911@provider.com;user=phone Location: <location> Accept-Contact: *;sip.service="urn:service:sos" INVITE sip:911@provider.com;user=phone To: sip:911@provider.com;user=phone IETF65 - ECRIT

  7. Problems with approach • No authentication  call alice@yahoo.com, mark as emergency call  get free call • assumes that IP calls are charged • unlikely that providers will just gateway to E.164 PSAP numbers • if mapping done by outbound proxy, next entity will be PSAP URL anyway • no home routing for emergency services! (visited service in IMS) •  only problem for UA rec/res • thus, could we punt? IETF65 - ECRIT

  8. 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  Call identification alternatives IETF65 - ECRIT

  9. Resolution: DDDS • (Most) URNs have a resolution mechanism  DDDS • Extract service part, e.g., “sos.fire” • Get domain D from local source: • DHCP  ISP as service provider • domain part of AOR  VSP as service provider • SIP configuration • Resolve NAPTR record for D:example.com. ; order pref flags service regexp replacement IN NAPTR 50 50 "u" "LOST+D2T" "!urn:service:(.*)!http://example.com/map/\1!i" . IETF65 - ECRIT

  10. Summary • Only two (known) open issues: • marking  can be separated, if needed • DDDS  needs NAPTR expert advice IETF65 - ECRIT

More Related