March 2006IETF65 - ECRIT1 Emergency Service Identifiers draft-ietf-ecrit-service-urn-01 Henning Schulzrinne Columbia University

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

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

March 2006IETF65 - ECRIT4 UA recognition & proxy resolution mapping INVITE urn:service:sos To: urn:service:sos Accept-Contact: *;sip.service="urn:service:sos" INVITE To: urn:service:sos Accept-Contact: *;sip.service="urn:service:sos" provider.com

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

March 2006IETF65 - ECRIT6 Proxy recognition & proxy resolution mapping INVITE To: INVITE To: Location: Accept-Contact: *;sip.service="urn:service:sos" provider.com

March 2006IETF65 - ECRIT7 Problems with approach No authentication  call 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?

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

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 "u" "LOST+D2T" "!urn:service:(.*)!

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