practical considerations for supporting emergency calls brian rosen emergicom
TRANSCRIPT
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