ECRIT - IETF 62 (March 2005) - Minneapolis 1 Requirements for Emergency Calling draft-schulzrinne-sipping-emergency-req-01 draft-ietf-sipping-sos-01 Henning Schulzrinne Dept. of Computer Science Columbia University

ECRIT - IETF 62 (March 2005) - Minneapolis 2 Requirements Components –Number provisioning –Identification –Location determination & insertion –Routing Issues –Protocol vs. operational requirements here, protocol-related requirements only –Protocol specific vs. generic

ECRIT - IETF 62 (March 2005) - Minneapolis 3 Logical steps dialed number  EC identifier route to PSAP verify address extract location determine language determine media determine location

ECRIT - IETF 62 (March 2005) - Minneapolis 4 Number provisioning Configure end system with digit strings that user dials to access emergency services –not the same as identifier in request A5/A6: Related to configuration problem –network boundaries may not conform to identifier boundaries country-spanning corporate networks provider-style networks –but typically national-scale, not local network When roaming, provide numbers for –visited country (“seen on firetruck”) –home country (“familiar from home”) Needs to support multiple services –some countries have separate service-specific numbers

ECRIT - IETF 62 (March 2005) - Minneapolis 5 Call Identification requirements A1: Universal system-visible identifier –may not be directly typed/dialed by caller A2: Recognize local emergency identifiers –where possible on call path A3: All entities along call path must be able to determine emergency call nature –may need to delegate call to entity that has location information end system  outbound proxy  provider home Allow multiple intermediate translations –“sos”  

ECRIT - IETF 62 (March 2005) - Minneapolis 6 Call identification requirements Backwards-compatibility –UAC may not understand identifier e.g., today’s soft client that allows SIP address important? handled via number recognition? –outbound proxies may not understand identifier –assume that “home” (AOR) domain does

ECRIT - IETF 62 (March 2005) - Minneapolis 7 Location identification requirements L1: multiple location providers –by reference, resolved in call path –end system –third party (outbound proxy) L2: Civic and geographic –done L3: Location source information included –already in PIDF-LO

ECRIT - IETF 62 (March 2005) - Minneapolis 8 Call routing Basic robustness requirement: –the UA or –outbound proxy or –home proxy (or proxies along the way) need to be able to do routing even if any of the other entities are unaware of non-SIP URLs or location-based lookup

ECRIT - IETF 62 (March 2005) - Minneapolis 9 Call routing requirements I1: correct PSAP I2: early routing (anywhere) I3: choice of PSAP – campus vs. city police I4: Assure PSAP identity I5: Traceable resolution –for caller or just PSAP? I6: assuring directory identity I7: assuring response integrity I8: update integrity

ECRIT - IETF 62 (March 2005) - Minneapolis 10 Call routing requirements I9: minimal call setup latency I10: no single (physical) directory –delegation by operational and jurisdictional needs I11: referral of mis-routed queries –only applies to some query protocols I12: multiple protocols (?) I13: robustness –outage or overload of directory services should not lead to wholesale failure –allow caching

ECRIT - IETF 62 (March 2005) - Minneapolis 11 Call routing requirements I14: incrementally deployable I15: testable I16: media-capability-based routing –e.g., allow separate facility for TDD or IM I17: language-based call routing –e.g., allow specialized metro-area facility

ECRIT - IETF 62 (March 2005) - Minneapolis 12 Caller identification requirements C1: reveal useful identity to PSAP –including network addresses C2: Privacy override possible –invocation is a local jurisdictional issue Language identification? Identification of supported media

ECRIT - IETF 62 (March 2005) - Minneapolis 13 Call setup and call requirements S1: authentication override –implementation issue S2: mid-call features –disable certain undesirable features, e.g., call transfer or hold –seems largely an implementation issue S3: Testable S4: Integrity of protocol flow

ECRIT - IETF 62 (March 2005) - Minneapolis 14 Testing/verification Non-interfering end-to-end call testing must be possible –subsumes address existence testing

ECRIT - IETF 62 (March 2005) - Minneapolis 15 Requirements-related open issues Protocol choices –SIP as external interface –allowing other protocols (MGCP, Skinny, H.323, ….) within administrative domains Agree on “PSAP” as terminology?