ESINET NG911. Aparna Pragadeeswar Vinoth

Transcription

1 ESINET NG911 Aparna Pragadeeswar Vinoth 1

2 Abstract This paper describes the SIP based VoIP architecture of NG911 that were built at the Main Campus of Illinois Institute of Technology, Chicago and Rice Campus of Illinois Institute of Technology, Wheaton. The SIP based VoIP architecture of NG911 relies on Emergency Services IP Network (ESInet). In addition, we paid special attention to layer 3 and layer 5 failover. We present and comment the results of layer 3 and layer 5 failover function. The rest of the software and tools that are described in the project were developed and provided by Columbia University and Texas A&M University. 2

3 Introduction public emergency communications services. IIT Real Time Communications (RTC) Research Lab. IP based system comprised of hardware, software, databases,servers, and other functional elements that provide Processing the emergency calls that deliver text, audio, video across the network. Acquire and data useful to call routing and handling from the sip entities. Deliver the calls/messages and data to location based PSAPs and other entities in the scenario. Manage IP networking that interconnects calls and data sources at failure scenario's. Maintain databases to manage routing and transfer of calls and data. 3

4 Project Goals The overall goal is to build a working model of the exciting ESINET in the RTC lab and build the layer 3, automatic layer 5 fail over functions that can be used for studies and developments in the areas of performance, operations, routing, failover, mobility. 4

5 Logical Architecture 5

6 Functional Elements SIPc: emergency caller and where the call originates. SOS calls client location information is hard coded. DNS Server: Ng911domain.zone file contains A, SOH,NAPTR records of sip url entities and there IP addresses. 6

7 LoST Server: Location to Service Translation protocol. PGAdmin11 application has the geo_us, civic databases. Mapping between location and sip url. Lost receives a query of location information of the SIPc caller and responds by providing the next nearest hop SIP URI. i) Public: responds by providing the next nearest ESRP URI. ii) Private: responds by providing the next nearest PSAP URI. It is located within the ESInet architecture. 7

8 SIPd: SIP caller proxy. caller is registered here. routes the call to the ESPR of the nearest ESInet. IP of esrp through the http query to public lost server. ESRP: Emergency Service Routing Protocol. Routing Proxy for the ESInet. routes the call to the nearest PSAP by http query to its private LoST server. The query/response to the private lost server will determine the destination address (URI) to which the emergency call is to be routed to the best suited PSAP. 8

9 Media Server Processes the audio and/or video streams associated with telephone calls or connections. Routes media from call talker to caller. The Dialogic has licensed it to ESINET PSAP: Public Safety Answering Point emergency service providers location. PSAPd is the PSAP which is responsible to forward call to an available call-taker (or service provider). Call Taker: Interface which call taker uses to answer the emergency 911 calls Call takers at rice as well as main campus scenerios. call taker application enables maps,text, audio and video of the call. 9

10 Physical Architecture 10

11 Call Handling Caller Call Taker ESINet 11

12 Typical Call Flow 12

13 Call Trace 13

14 Layer 3 Failover Scenario and Solution The layer 3 failover occurs when the PSAP is not functioning properly. Under lab circumstances the layer 3 failover was achieved by manually plugging out the network cable of PSAP. This was solved by assigning priority in the DNS sever. The PSAP in the main campus has the first priority in main campus and the second priority is assigned to Rice campus PSAP. If a layer 3 failover occurs in main campus the call will routed to Rice campus PSAP. 14

15 Layer 5 Failover Scenario and Solution The layer 5 failover occurs when any SIP functional element that fails. This can be solved by adding script in two places, either in ESRP or PSAP. If a FE fails then it must be replaced by a backup or alternative FE that performs the identical functions. We can send OPTIONS requests and note if they are not responded to. By adding the script in ESRP, the call can be routed to another PSAP by changing the uri. 15

16 Conclusion This project has been an incredible opportunity for us to both learn and develop innovative solutions. Stability of the architecture is an important responsibility that we took very seriously throughout the semester. In addition, the real-time implications of this project are very motivational and encourage us to work on the project and develop new solutions. 16

17 Thank you 17