html5-img
1 / 22

Emergency Calling for VoIP

Emergency Calling for VoIP. Wonsang Song, Jong Yul Kim, and Henning Schulzrinne. Overview. Project introduction Architecture and implementation References Demo. Introduction. Emergency call is necessary for voice service. People expect to reach PSAP when dials 911.

Download Presentation

Emergency Calling for VoIP

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. Emergency Calling for VoIP Wonsang Song, Jong Yul Kim, and Henning Schulzrinne

  2. Overview • Project introduction • Architecture and implementation • References • Demo

  3. Introduction • Emergency call is necessary for voice service. • People expect to reach PSAP when dials 911. • Many people use VoIP as primary telephone. • Traditional 9-1-1 system does not work well with VoIP • Identity = Line number, Location = billing address • Covering limited area • National protocols and routing • Three (related) fundamental problems • Where is the caller? • To which PSAP should the call go to? • How to identify the emergency call?

  4. Project Goals • Develop a prototype system that routes emergency calls over SIP based VoIP networks. • Implement requirements for IP-based PSAP • Provide opportunities to enhance 911 system: • Multimedia (audio, video, text) • Data delivery (floor plan, medical information) • Delivering video (CPR how-to) • Load balancing and redundancy • Location delivery (location with forwarded, transferred calls)

  5. Four Phases of Emergency Calls Phase 4 Phase 1 Phase 2 Phase 3

  6. System Components phase1 phase1 phase2 phase3 phase3 phase4

  7. Phase1: Determining Location • Purpose • To get the visited emergency dial strings (Phase2) • To resolve the correct PSAP URL (Phase3) • To present the caller’s location on the call taker’s screen using mapping software (Phase4) • Solution • UA can be stationary, nomadic or mobile -> apply different methods • GPS, CDP (LLDP-MED), DHCP and Manual Entry • The result location information is either civic address or geospatial coordinates. • The location information will be included in the INVITE request as PIDF-LO.

  8. DHCPINFORM [MAC=00:11:20:9d:a0:03] request or response DHCPACK [option=0:US:1:NY:2:NEW YORK: 3:NEW YORK:6:AMSTERDAM:19:1214] DHCP Server DHCP for Location • modified ISC’s dhcpd to generate location information • use MAC address back-tracing to get location information

  9. CDP for Location • Cisco Discovery Protocol (Layer2) • Cisco switches broadcast switch/port ID periodically. • A Switch covers a floor, a port leads to a jack in a room -> room-level accuracy

  10. SIP message for Location Info. ------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY= MIME-Version: 1.0 Content-Type: application/pidf+xml Content-Transfer-Encoding: 8bit <?xml version="1.0" encoding="ISO-8859-1"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0" entity="sip:calltaker_ny2@irt.cs.columbia.edu"> <tuple id="28185"> <status> <gp:geopriv> <gp:location-info> <cl:civilAddress> <cl:country>us</cl:country> <cl:A1>ny</cl:A1> <cl:A2>new york</cl:A2> <cl:A3>new york</cl:A3> <cl:A6>amsterdam</cl:A6> <cl:HNO>1214</cl:HNO> </cl:civilAddress> </gp:location-info> <gp:method>Manual</gp:method> </gp:geopriv> </status> <contact priority="0.8">sip:eddie@160.39.54.70:5060</contact> <timestamp>2005-09-26T15:57:34-04:00</timestamp> </tuple> </presence> ------- =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY=-- INVITE urn:service:sos SIP/2.0 request line To: urn:service:sos Call-ID: 763782461@192.168.1.106 Via: SIP/2.0/TCP 192.168.1.106:4064;rport Content-Type: multipart/mixed; boundary From: sip:caller@irt.cs.columbia.edu Contact: <sip:eddie@160.39.54.70:5060> CSeq: 1 INVITE Content-Length: 1379 header fields ------ =_ZGY1NTFlZDJkMDkxY2FkMTIxMWI2MzIzNjE1M2U0OTY= MIME-Version: 1.0 content-Type: application/sdp Content-Transfer-Encoding: 8bit v=0 o=eddie 1127764654 1127764654 IN IP4 192.168.1.106 s=SIPC Call c=IN IP4 160.39.54.70 t=0 0 m=audio 10000 RTP/AVP 0 3 m=video 20000 RTP 31 SDP PIDF-LO

  11. Phase2: Identifying SOS • Purpose • For UA : To send caller’s location information • For Proxies: To handle the emergency call specially • Emergency Identifier (Emergency Service URN) • Service URN: identifies a generic service, not a specific resource • For emergency: • urn:service:sos • urn:service:sos.ambulance • urn:service:sos.fire • urn:service:sos.police • … • Can be used in request URI and To header. • Will be resolved into PSAP URL using mapping service (phase3)

  12. Emergency Dial Strings • Different emergency dial strings • different in countries (e.g., 911 for North America, 112 for Europe) • some countries uses separate numbers for ambulance/police/fire • Required to support both home and visited emergency dial strings • e.g., for an American traveler who is visiting Europe, both 911 and 112 should be recognized as emergency • For the home emergency dial strings: • User can set his/her home country through configuration. • In initial time, UA gets the home emergency dial strings using mapping protocols. • For the visited emergency dial strings: • Whenever current location is changed, UA gets the visited emergency dial strings using mapping protocols. • UA keeps all emergency dial strings in the local dial plans e.g., [911 -> urn:service:sos]

  13. Caller’s location Service provider (PSAP URL) + Service identifier (urn:service:sos) Phase3: Routing to Correct PSAP • Which PSAP should the call go to? • Usually to the PSAP that covers the area • Sometimes to a backup PSAP • If no location, then ‘default’ PSAP • PSAP determination • mapping problem: • Works in progress for standardization • LoST: A Location-to-Service Translation Protocol

  14. LoST(Location-to-Service Translation) • For mapping a service identifier and location information to {PSAP URL & emergency dial-string} • Supports both civic and geo location information • Uses web service (SOAP base) as underlying protocol <mapping> <response expires="2006-03-09T01:53:33.396Z"> <service>urn:service:sos</service> <displayName>New York City PSAP</displayName> <uri>sip:psap_ny@irt.cs.columbia.edu</uri> <civicMatch> <gp:location-info> <cl:civicAddress> <cl:country>US</cl:country> <cl:A1>NY</cl:A1> <cl:A3>New York</cl:A3> <cl:A6>Amsterdam</cl:A6> <cl:HNO>1214</cl:HNO> </cl:civicAddress> </gp:location-info> </civicMatch> <dialstring>911</dialstring> </response> </mapping> <mapping> <request> <operation>recurse</operation> <service>urn:service:sos</service> <gp:location-info> <cl:civicAddress> <cl:country>US</cl:country> <cl:A1>NY</cl:A1> <cl:A3>New York</cl:A3> <cl:A6>Amsterdam</cl:A6> <cl:HNO>1214</cl:HNO> </cl:civicAddress> </gp:location-info> </request> </mapping> request response LoST Server

  15. (8) join conference join conference (5) (6) REFER police to conference (7) INVITE to conference (4) INVITE to conference (3) select available call taker (2) create conference (1) psap@domain w/location Phase4: Call Presentation in PSAP

  16. Calltaker’s Screen • SIPc as SIP UA • Mapping software to display caller’s location • Geolynx • Google Maps

  17. Web Interface • Manage PSAP systems • Show call logs, details, incident information and statistics

  18. (2) Location + Service Identifier (1) Location (3) PSAP URL + emergencydial-string (4) INVITE PSAP URL To: urn:service:sos <Location> INVITE PSAP URL To: urn:service:sos <Location> (6) (5) dial emergency dial-string or push emergency button Scenario 1: Normal Case(UA recognition, UA resolution) Mapping Server SOS caller SIP proxy call taker

  19. INVITE PSAP URL To: urn:service:sos <Location> (6) Scenario 2: No Location from UA(UA recognition, Proxy resolution) DHCP Server Mapping Server (5) (4) PSAP URL Location + Service Identifier (3) Location (1) INVITE urn:service:sos To: urn:service:sos (2) dial 911 or push emergency button SOS caller SIP proxy call taker

  20. Scenario 3: Backward Compatible(Proxy recognition, Proxy resolution) DHCP Server Mapping Server (5) (4) PSAP URL Location + Service Identifier (3) Location (1) (2) INVITE sip:911@domain To: sip:911@domain INVITE PSAP URL To: urn:service:sos <Location> (6) SOS caller dial 911 SIP proxy call taker

  21. SIP: Session initiation protocol, RFC 3261 Requirements for Emergency Context Resolution with Internet Technologies, draft-ietf-ecrit-requirements-04 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information, draft-ietf-geopriv-dhcp-civil-07 Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information, RFC 3825 A Presence-based GEOPRIV Location Object Format, RFC 4119 A Uniform Resource Name (URN) for Services, draft-ietf-ecrit-service-urn-01 LoST: A Location-to-Service Translation Protocol, draft-hardie-ecrit-lost-00 Best current practices for third party call control (3pcc) in the session initiation protocol (SIP), RFC 3725 References

  22. Demo

More Related