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

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

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

5. UA recognition & proxy resolution (proxy location determination)
mapping
9-1-1
provider.com
INVITE
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"
March 2006
IETF65 - ECRIT

6. Proxy recognition & proxy resolution
mapping
9-1-1
provider.com
INVITE
To:
INVITE
To:
Location: <location>
Accept-Contact: *;sip.service="urn:service:sos"
March 2006
IETF65 - ECRIT

7. 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 2006
IETF65 - ECRIT

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

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