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 9-

1-1 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)

3rd 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 3rd 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