Emergency Calling for VoIP: A Progress Report Henning Schulzrinne (with Anshuman Rawat, Matthew Mintz-Habib, Xiaotao Wu and Ron Shacham) Dept. of Computer Science Columbia University VON – October 19, 2004 (Boston, MA)

Overview Problem summary Requirements and opportunities I1, I2, and I3 Competing visions Early prototype implementations

Core long-term requirements Media-neutral voice (+TDD) first, IM and video later Work in systems without a voice service provider many enterprises will provide their own local voice services Allow down-stream call data access as well as access to other “tertiary” data about the incident Globally deployable independent of national emergency number (9-1-1, 1-1-2, etc.) respect jurisdictional boundaries – minimize need for cross-jurisdictional coordination allow usage even if equipment and service providers are not local travel, imported equipment, far-flung locations Testable: verifiable civic addresses (“MSAG validation”) call route validation Secure and reliable

Standardization efforts IETF (Internet Engineering Task Force) SIP and DNS usage possibly new protocols for lookups BOF (pre-WG) at upcoming IETF meeting in Washington, DC NENA (National Emergency Number Association) requirements based on operational needs of PSAPs I2 (mid-term transition) protocols for mapping EMTEL (Europe) getting started

Three stages to VoIP 911 I1 I2 I3 spec. available? use 10-digit admin. number? mobility callback number to PSAP? caller location to PSAP? PSAP modification ALI (DB) new services I1 now allowed stationary no none I2 Dec. 2004 nomadic yes no (8 or 10 digit) update I3 late 2004 mobile IP-enabled ALI not needed MSAG replaced by DNS location in-band GNP multimedia international calls

Location, location, location Location  locate right PSAP & speed dispatch In the PSTN, local 9-1-1 calls remain geographically local In VoIP, no such locality for VSPs most VSPs have close to national coverage Thus, unlike landline and wireless, need location information from the very beginning Unlike PSTN, voice service provider doesn’t have wire database information VSP needs assistance from access provider (DSL, cable, WiMax, 802.11, …)

I3 (long-term) architecture components Common URL for emergency calls sips:sos@home-domain Convey local emergency number to devices Allow devices to obtain their location directly via GPS indirectly via DHCP locally via LLDP (802.1ab, TIA LLDP-MED) initially, often through manual configuration Route calls to right destination using look-up in device or proxy

I3: Location-based call routing – UA knows its location GPS INVITE sips:sos@ 48° 49' N 2° 29' E outbound proxy server DHCP 48° 49' N 2° 29' E  Paris fire department

Transition: I2 PSAPs won’t convert to VoIP overnight Need to support 9-1-1 services sooner Rely on components used for Phase II wireless Assumes voice service provider (VSP) (Hopefully) more complicated than I3 solution…

I2 architecture (draft) DBMS IP domain Emergency Services Provider Network Call server/ proxy server PSTN Routing Proxy & Redirect server(s ) MSAG E9 - 1 Selective Router VDB v6 ALI DB ESGW(s ) v5 v4 v4 E9 - 1 - 1 ESZ RDB DHCP Selective PSAP DNS v1 Router LIS IP Domain v2 User v2 VPC Agent VPC SRDB VPC v - e2 v0 ALI DB v8 v3 v7 location information service VoIP positioning center routing database validation database

Different perspectives MSAG & routing data provided by (national-scale) database vendors bottom-up: offered by PSAPs and jurisdictions MSAG and routing data proprietary and not available to public open data specialized protocols for emergency services avoid specialized protocols at all cost specialized, dedicated emergency services networks fortified networks, but with rich Internet connectivity slow transition to I3 (decades) if possible, make I2 period a matter of years or skip I2

I2 interfaces Participants Protocol(s) Description v0 v1 v2 v3 v4 v5 LIS to UA DHCP conveys location to endpoint v1 UA to CS SIP (+ others) recognize emergency call transport location object v2 Proxy to VPC XML query/response location  ESRN, ESQK v3 VPC to LIS ? VPC gets location from location key in signaling message v4 CS/routing proxy to ESGW SIP ESRN and ESGW inserted v5 CS to redirect server Redirect server returns call routing information (ESRN, ESQK) in 3xx v6 CS to routing proxy v7 location validation DNS, ? LIS requests validation of address v8 VPC to ERDB VPC sends LO, gets ESQK ve-2 VPC to ALI-DB E2+ (wireless)

I2 example (embedded LO)

Current IETF documents draft-taylor-sipping-emerg-scen-01 (expired) scenarios, e.g., hybrid VoIP-PSTN draft-schulzrinne-sipping-emergency-req-01 abstract requirements and definitions draft-schulzrinne-sipping-emergency-arch-02 overall architecture for emergency calling draft-ietf-sipping-sos-00 describes ‘sos’ SIP URI draft-rosen-dns-sos-01 new DNS resource records for location mapping RFC 3825 “Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information” draft-ietf-geopriv-dhcp-civil-04 DHCP option for civic addresses

Components sipd sipc SIP proxy server database-backed DNS server SIP phone web server SQL database for call routing sipc SIP user agent geo-coding, PSAP boundaries GIS software for call location plotting No endorsement implied – other components likely will work as well

I3 prototype * gray features in progress.

Detail: I3 - DNS-based resolution DHCP INFORM psap.state.vt.gov SIP w/location MAC  loc Perl sip-cgi script psap.state.vt.gov DNS NAPTR: addison.vt.us algonquin-dr.addison.vt.us … proprietary TCP-based protocol 151.algonquin-dr.addison.vt.us.sos-arpa.net

Call taker setup SIPc client receives calls GeoLynx software displays caller location

GeoLynx displays location GeoLynx listens for commands from SIPc

Emergency call conferencing PSAP brings all related parties into a conference call Hospital Fire department REFER INVITE INVITE Conference server REFER INVITE INVITE media info Recorder INVITE 3rd party call control REFER INVITE media info PSAP Caller

Scaling NENA: “estimated 200 million calls to 9-1-1 in the U.S. each year”  approximately 6.3 calls/second if 3 minute call, about 1,200 concurrent calls typical SIP proxy server (e.g., sipd) on 1 GHz PC can handle about 400 call arrivals/second thus, unlikely to be server-bound

Conclusion 9-1-1 core enabling service for consumer-grade VoIP Progress on defining I2 and I3 but fundamental architectural assumptions differ I2-I3 transition likely to be gradual and in parts Early prototypes are being demonstrated IETF working group likely to be established soon