1 / 21

Practical Considerations for supporting Emergency Calls

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

orenda
Download Presentation

Practical Considerations for supporting Emergency Calls

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Practical Considerations for supporting Emergency Calls Brian Rosen Emergicom

  2. 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

  3. The “Sierra Leone” problem • Patron at a Starbucks café has a laptop with WiFi connection to the 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

  4. Sierra Leone cont. – So What? • The Starbucks is in Chicago • The employer is Sierra Leone Trading Intl • Its VSP is Sierra Leone VoIP Services Pty • Its 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

  5. 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

  6. 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)

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

  8. 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 • Or check out LLDP-MED • 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 phones • Location to building/suite/floor/room can be specified

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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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)

  15. 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

  16. 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

  17. Voice Service Providers • For i2, you contract with a “VPC” operator and an “ESGW” operator (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

  18. That i2 picture again

  19. 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

  20. 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

  21. 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

More Related