march 2006ietf65 - ecrit1 emergency service identifiers draft-ietf-ecrit-service-urn-01 henning...

10
March 2006 IETF65 - ECRIT 1 Emergency Service Identifiers draft-ietf-ecrit-service-urn-01 Henning Schulzrinne Columbia University [email protected]

Upload: julian-park

Post on 23-Dec-2015

212 views

Category:

Documents


0 download

TRANSCRIPT

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

March 2006 IETF65 - ECRIT 1

Emergency Service Identifiersdraft-ietf-ecrit-service-urn-01

Henning Schulzrinne

Columbia [email protected]

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

March 2006 IETF65 - ECRIT 2

Open Issues

• Identifying the call post-resolution

• Server resolution

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

March 2006 IETF65 - ECRIT 3

UA recognition & UA resolution

INVITE sip:[email protected]: urn:service:sosAccept-Contact: *;sip.service="urn:service:sos"

<location>

9-1-1(dial string)

mapping

INVITE sip:[email protected]: urn:service:sosAccept-Contact: *;sip.service="urn:service:sos"

<location>

leonianj.gov

mapping may recurse

location information

DHCPLLDP-MED

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

March 2006 IETF65 - ECRIT 4

UA recognition & proxy resolution

9-1-1

mapping

INVITE urn:service:sosTo: urn:service:sosAccept-Contact: *;sip.service="urn:service:sos"

<location>

INVITE sip:[email protected]: urn:service:sosAccept-Contact: *;sip.service="urn:service:sos"

<location>

provider.com

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

March 2006 IETF65 - ECRIT 5

UA recognition & proxy resolution(proxy location determination)

9-1-1

mapping

INVITE urn:service:sosTo: urn:service:sosAccept-Contact: *;sip.service="urn:service:sos"

INVITE sip:[email protected]: urn:service:sosLocation: <location>Accept-Contact: *;sip.service="urn:service:sos"

provider.com

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

March 2006 IETF65 - ECRIT 6

Proxy recognition & proxy resolution

9-1-1

mapping

INVITE sip:[email protected];user=phoneTo: sip:[email protected];user=phone

INVITE sip:[email protected]: sip:[email protected];user=phoneLocation: <location>Accept-Contact: *;sip.service="urn:service:sos"

provider.com

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

March 2006 IETF65 - ECRIT 7

Problems with approach

• No authentication call [email protected], 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?

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

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

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

March 2006 IETF65 - ECRIT 9

Resolution: DDDS

• (Most) URNs have a resolution mechanism DDDS1. Extract service part, e.g., “sos.fire”2. Get domain D from local source:

1. DHCP ISP as service provider2. domain part of AOR VSP as service provider3. 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" .

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

March 2006 IETF65 - ECRIT 10

Summary

• Only two (known) open issues:– marking can be separated, if needed– DDDS needs NAPTR expert advice