1. March 2006IETF65 - ECRIT1 Emergency Service Identifiers draft-ietf-ecrit-service-urn-01 Henning Schulzrinne Columbia University hgs@cs.columbia.edu

2. March 2006IETF65 - ECRIT2 Open Issues Identifying the call post-resolution Server resolution

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

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

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

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

7. March 2006IETF65 - ECRIT7 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?

8. March 2006IETF65 - ECRIT8 Call identification alternatives 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

9. March 2006IETF65 - ECRIT9 Resolution: DDDS (Most) URNs have a resolution mechanism  DDDS 1.Extract service part, e.g., “sos.fire” 2.Get domain D from local source: 1.DHCP  ISP as service provider 2.domain part of AOR  VSP as service provider 3.SIP configuration 3.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".

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