Practical Considerations for supporting Emergency Calls Brian Rosen Emergicom

Emergency calls are fundamental to deploying VoIP Doesn’t matter if you are a service provider or an enterprise, you must have provisions for emergency calls There is significant liability if you don’t do something appropriate – At least after there are defined standards – As of the end of this year, in North America, there will be The more flexibility you offer your customers/employees, the harder it is

The “Sierra Leone” problem Patron at a Starbucks café has a laptop with WiFi connection to Internet VPN Tunnel exists to Patron’s employer Softclient on laptop connected to employer’s VoIP PBX An accident happens, and the patron dials for help

Sierra Leone cont. – So What? The Starbucks is in Chicago The employer is Sierra Leone Trading Intl It’s VSP is Sierra Leone VoIP Services Pty It’s ISP is Cable and Wireless Starbucks uses T-Mobile to supply the hotspot There are no contractual relationships except that between S.L. Trading and S.L. VoIP There is clearly no contractual, legal or other relationship between the Chicago PSAP and any entity in Sierra Leone

How this will work (at least at i3) The phone learns its location from the LOCAL environment – DHCP supplies location when the laptop gets it’s IP address – This is the right location, before the VPN tunnel is established Location is carried in the signaling, with the call There is an available routing database so that anyone, worldwide, can route the call to the correct PSAP

Routing is non trivial, especially in North America There are approximately 6,134 PSAPs in North America Each has a service boundary They are NOT necessarily aligned to any political (state/county/city) boundary Call must be routed to the correct PSAP There are databases that exist for civic and geo locations that tell you where to route the calls But currently, access to them is restricted, and has cost associated with it Other areas are easier (one PSAP for a country) others are harder (no existing database)

Location In Enterprises Getting to the right “address” is not enough – Think of this as the “yelling” test All enterprises who have large facilities will need to provide more specific location information We’re going to make this as easy as possible, but it’s still going to be some level of burden on enterprise

Making Location work in Enterprise VoIP Same basic idea – phone learns location from its local environment – Could be proprietary to your VoIP vendor – Standards based approaches are feasible now – RFC3046 describes a mechanism to determine the switch port a packet arrived on This gives you the basis to use a (manually maintained) wiremap database (room number to switch port) to determine location – and that is where the cost is DHCP can be used to supply this location to endpoints Location to building/suite/floor/room can be specified

Location for Residential VoIP Voice Service Providers don’t have much of a role because they don’t know where the customer is AND THEY DON’T HAVE A RELATIONSHIP WITH ANYONE WHO DOES The ISP may or may not know, but if they don’t they have a relationship with someone who does The Access Infrastructure Provider knows where the customer is

Access Infrastructure Providers “First Mile” infrastructure owner, wireline or wireless Wireline AIPs already have a notion of a Service Address, and a wiremap (or equivalent) database I believe ALL AIPs, regardless of technology, and regardless of whether they offer voice/video/text services, must supply location It’s likely that regulation will be required, and it’s likely to happen Fixed wireless (e.g. WiMax) vendors; plan on GPS receivers or triangulation mechanisms You heard it here first

ISPs If you are the AIP, you supply location to endpoints If you aren’t, contract with the AIP to get it If there is a system spec on all infrastructure including all end points, you can use any mechanism you like to get location to the endpoint If you don’t have such control, support at least DHCP

Cascaded Location Applicable to things like WiFi “AP” gets location from its environment, and relays it to its endpoints If possible, supply more specific location – The “yell test” again Works for things like café hotspots

Next Up = SIP Phone Vendors You have to get location from the environment as described If you do digit analysis in the phone, you have to learn the local emergency call number for the environment the phone is in – We are working on standards for this When you detect an emergency call, or the downstream proxy tells you its an emergency call, you must supply location

SIP Phone Vendors, cont. Because location is sensitive, IETF standards REQUIRE sips (TLS) for emergency calls PLEASE implement this now, pretty please Supply a good callback in Contact – Good as in, “reachable from the PSAP” Implement blind and supervised transfer (REFER/Replaces) 3 rd Party Call Control (for conferencing)

SIP Proxy Vendors – Your turn For i3, you need to implement routing based on location – This is the charter of the new IETF working group – The DNS based approach will work, others may or may not, we’ll see You have to implement TLS too Allow callback from the PSAP – Probably more a configuration thing

What if you don’t support SIP? The standard interface to PSAPs, at least in North America, will be SIP Other vendors will have to gateway to SIP to send emergency calls Most vendors already support SIP, because most inter-enterprise/inter-carrier peering is SIP Must include location, as per SIP standards on the call

Voice Service Providers For i2, you contract with a “VPC” operator and an “ESGW” vendor (could be the same entity) Three different ways to hand off calls – Unconditional SIP handoff – Query VPC, choose ESGW – SIP Handoff, with redirect back to you to select ESGW

That i2 picture again

More VSP Responsibilities Deploy TLS – So, beat up your (SBC) vendors. It’s the Right Thing To Do For i3, much simpler routing decision – Look up location in a database (DNS for example) – Forward call to where it says to – No 3 rd parties Allow callbacks to Contact header May need identity assertions

Other communications service providers have a role too Video telephony/conferencing vendors, i3 PSAPs will take the calls – Also applies to camera phones IM vendors, i3 PSAPs will take the calls And for everyone, there will be a new generation of “TDD” devices based on SIP and interactive text streams. Please plan on supporting them

Summary Emergency Calls are important, and not some one else’s problem Voluntary compliance forestalls heavy regulation Participate in the standards work if you are interested Plan for deployments NEXT YEAR