Due to the growing popularity of voice over data facility in today's communication system it has become important for our emergency 9-1-1 system to support voice over data facility. Hence, National Emergency Number Association(NENA) has proposed Next-Generation 9-1-1(NG9-1-1) system to support media convergence and data support to the currently used 9-1-1 System [1]. The NG-911 architecture contains a very critical node which manages the call routing at the Emergency Call Centre. Here, in this report we present the design and implementation of the Public Safety Answering Point developed by us at the Columbia University, New York.
The work described in the report explains the architecture and software developed for the PSAP node in the NG-911. PSAP is a SIP and HTTP converged application which manages calls inside a NG-911 call centre. Whenever, a call comes, PSAP checks the list of available calltakers and decides on the basis a given algorithm on which calltaker should be assigned the call. It then notifies this calltaker about the new incoming call. After the call being accepted, the PSAP forwards the call to the SIP phone of the calltaker. This way the PSAP acts a single point of interface for the whole call-centre.
Session Initiation Protocol is an application layer protocol to maintain multimedia sessions over the IP network. It has gained wide popularity due to its simple yet sufficiently detailed protocol specification to maintain sessions between two or more entities communicating multimedia messages. It is interesting to note that SIP has got nothing to do with the actual data packets and it just establishes a stable session between entities who want to exchange multimedia messages. The most important SIP messages we will be discussing here are INVITE, REGISTER, CANCEL and BYE. INVITE message is sent by an entity asking the peer SIP entity for a SIP session. REGISTER message is sent by an entity to supply its IP address and other important parameters to the communicating element viz. B2BUA or a SIP Proxy. CANCEL message is sent by a client, if it wants to cancel a call after sending an INVITE but before receiving a 200 OK response. BYE message is used to tear the call. [3]
We are using SIP servlets in Java in our implementation of PSAP. SIP servlet is a Java API support which helps establish SIP signaling between the app lications. They completely understand the SIP messages and help the programmer to define the functionality of the application through their API support. SIP servlets are built over the Java Servlet Specification and hence programmers experienced with HTTP servlets find it very easy to write applications with SIP servlets. But, it is important to realize certain differences between the SIP servlet and the HTTP servlet [4] –
- There is no concept of context parallel that in HTTP servlets
- Due to the functionality defined for SIP, the SIP servlets can generate multiple responses for the same request unlike HTTP servlets
SIP servlet provide a list of methods which are invoked when these particular kind of messages are received by the application. There are several methods like doRegister, doRequest, do Response, doAck, doErrorResponse, doCancel etc. A complete list of such methods can be found in [3] [4]. These methods maintain a hierarchical structure through internal inheritance. A SIP application developer needs to write these methods in his application according to the functionality of the application being developed. All these methods are empty and the application developers methods override them. If a particular incoming message message is not overridden, then that message is replied with SIP error message [4].
PSAP is primarily a Back to Back User Agent (B2BUA). A B2BUA is a network element that communicates between SIP proxies and clients. In an SIP session using a B2BUA, SIP flow is set-up between the client or the proxy and the B2BUA. Hence, two communicating SIP entities communicate to each other via the B2BUA. The B2BUA typically mediates all the messages coming from one entity to the other such that it appears to these entities that they are communication just to the B2BUA but in fact these entities are exchanging messages between each other without knowing so.
The logic behind PSAP being a B2BUA is because to the external world there shall be only one access point to a particular 9-1-1 call centre although there may several tens or hundreds of call takers serving each call centre. Hence, PSAP provides a single interface to connect all these call centre call takers. This reduces the complexity of each call taker SIP clients being registered and maintained by external entities there by maintaining simplicity.
To create such B2bua application, the B2buaHelper class in Java is typically very helpful. Generally, it is a very common trend in applications like ours that a middle endpoint is required for communication between two SIP parties. Hence, development of such application has become very frequent. Typically, without the use of B2bua helper class, an application developer would have to create the packets coming from one end of a SIP leg for the other leg of the SIP session. Hence, to utilize code reuse and decrease the programming errors, B2buaHelper class was introduced. With this, two SIP sessions can be linked together and messages coming from one leg can be forwarded to the other leg with minimum required changes in the SIP packet. With such kind of support, the application developer will just have to concentrate on the application part and the overall SIP call flow rather than the programming aspects of the application development.
A typical B2buaHelper for a sip session can be retrieved as follows:
B2buaHelper b2buaHelper = request.getB2buaHelper();
Once we have the b2buaHelper, we can easily create an incoming message to be sent to the other leg as follows:
SipServletRequest nextLegRequest = b2buaHelper.createRequest(request, true, headerMap);
Here, the request is the Sip request we have received and want to forward to the other leg of the application. True flag indicates to the application that a new SIP session shall be created if the is no SIP session for the other SIP leg. headerMap is an important parameter which helps the application developer do the required changes in the SIP message being forward to the other leg. This is typically a map interface and is of the form:
java.util.Map "<"java.lang.String, java.util.List"<"java.lang.String">"">"
This is how we have used B2buaHelper class to develop the PSAP.
PSAP provides the support for a web interface too. The Web Interface is web based support to control the call routing. We are providing, a web interface to the PSAP for the following purposes:
- To enable username password login facility for security purposes
- To point the location of the emergency caller on the Google Map on the web Interface [5]
- To notify to a call taker about a new incoming call to be accepted
- To provide name of the call taker as received in the SIP message to the call taker even before the call is accepted
We have used Java Server Pages to develop the web frontend interface of the application. JSP is a very convenient web technology which uses the power of Java to create web pages. In simple words, in JSP we can put Java code inside the HTML files so whenever the page is requested from a client, the Java code is run on the server which creates a complete HTML page which his then sent as a response to the client. It is important to realize the difference between HTTP servlets and JSP, and the easiest way to put this is that in HTTP servlets, the HTML code is written inside Java code where as in JSP, java code is written in side HTML. This primary difference helps us to chose what we must use in a particular application. According to what I have realized, if there is a lot computation being done on the server side of the HTTP session we must use HTTP servlet but otherwise JSP comes pretty handy. We have used JSP on the server side for similar reasons as not much computation is being done on the server side of the HTTP session and most of the information is simply picked up from the SIP servlets.
In addition to this, we are using JavaScript and Ajax technology to create dynamic pages. Our client web interface is very dynamic, meaning that the client page should continuously be with the information about incoming calls. Hence, one way is to continuously reload the html page using an onload reload functionality in HTML. But, using this creates a flickering affect on the webpage and this is not a very optimal solution to the problem. Hence, we are using AJAX technology which keeps on retrieving data from the server and only updates the pertinent part of the web page. With this solution logically, only a part of the webpage is reloaded periodically rather than the whole webpage. This pertinent part includes the code for button on the calltaker screen, Caller Information, the status of the calltaker viz. “Available”, “Busy”, “Phone not Registered”.
In addition, to this we are using Google map to display the location of the caller on the web interface of the calltaker. In our application, we are extracting the latitude and longitude values from the INVITE message received from the calltaker, available in its message body. We supply this information to the Google Maps which displays the location of the caller on the web interface of the calltaker.
In this section, we discuss the implementation of the PSAP explaining the different modules in the source code. We will also include a discussion on the interaction of all these small modules with each and how they together build a PSAP application.
The most important class in our code is Psap.java. This class extends javax.servlet.sip.SipServlet and defines several methods which override the methods defined in the SipServlet. We shall start discussing about these methods case by case –
This methods registers a particular calltaker at the PSAP. Practically, whenever a calltaker registers their SIP phone with PSAP, a register message is sent from the phone. This message contains several fields like To, From, Call-Id, Contact, CSeq etc. but the most important field to us is the SIP uri in the from field of the message. Using this field, we extract the logical address of the calltaker. We also get the display name of the calltaker which in our application has to be same as the username for login purposes. This we have done to avoid confusion between the web login username and SIP protocol name. We hence, take out the username of the calltaker and the ip address from the from field and store it to the HashMap maintained at the PSAP. With this, whenever a new call comes we can get the details of the calltakers and populate the headerMap in the createRequest method of the B2buaHelper using the SIP uri we have stored in the HashMap. We also add this calltaker to the list of available call takers and initialize the status of this calltaker as available.
This method is invoked when a caller sends an INVITE to the PSAP. In such a case, we select one of the available calltakers using a random algorithm over the list of available calltakers we have. Once, we have selected a calltaker we put this calltaker in the list of checkStatusPending list which indicates to the calltaker that they have been chosen to receive this call. At this time through the mechanism explained later, the web UI of the calltaker will notify this new call. We further get the latitude and longitude of the user through the information present in the INVITE message from the caller. We add this to the TakerLocationMap which maps the calltaker selected and the location of the caller it is serving. Once, the calltaker selects accept on his web screen, the INVITE is forwarded to the SIP phone of the calltaker.
It is important to note that all this is done only if the emergencyAvailable set is non zero. If the set is zero, we send an SC_BUSY_EVERYWHERE message back to the caller indicating that all the calltakers are busy.
On receipt of such a message by the PSAP, it checks the SIP method of the message. If the method is not BYE, the response is simply forward to the other leg of the linked session. If the method is BYE then we update the emergencyAvailable list with the username of the calltaker, change the userCallStatus to “Available”, remove the corresponding entry from the CallerNameMap and the TakerLocationMap. This assures a clean teardown of the call.
If CANCEL is received from the calltaker we again update the emergencyAvailable list, userCallStatus, CallerNameMap and TakerLocationMap. In addition to this, the cancel message is forwarded to the other leg of the SIP session.
if BYE is received, we create a BYE request and send it to the other leg of the SIP session. All the records maintained are cleaned as mentioned above. The BYE message is also checked to see the origin of the message so that we can differentiate between the calltaker and caller, and remove the corresponding entries correctly.
The next file we discuss is User.java. This file contains several HashMap and ArrayList which help us maintain the information of all the calltakers and ongoing calls. We here discuss the records being kept by these HashMap and ArrayList.
In addition to the above methods being use for the call management, we explain the functionalities of the JSP files below:
This page takes the username and password from the user and sends it to userCheck.jsp
This page checks the username and password received from the LoginPage.jsp. Depending upon the result it redirects the user to MainPage.jsp if the username and password are correct otherwise it outputs that username or password is not correct.
This page is the main call control page which displays contents of button.jsp which is periodically retrieved from the server and displays the Google Map using the contents of the map-simple.jsp page. This page actually implements AJAX for fresh updates from the server.
This page is the one which is periodically called by MainPage.jsp. This page contains availability status of the calltaker, the name of the caller, location of the caller and if there is a new call for the calltaker, it displays a button to accept the call.
This page is called when the calltaker presses the accept button on his web interface. With this, the user is removed from the callStatusPending List, the status of the calltaker is set to false or busy, the calltaker is removed from the emergencyAvailable list.
This page displays the google map with marker on the point specified by the latitude and longitude of the caller.
This page is called when the logout is pressed by the user on the MainPage.jsp. The page invalidates all the session parameters for the user.