Integration with 911 dispatch center using Azure and SignalR (part 1)

People who know me know me as passionate about software development and being a volunteer fire fighter. As a developer you always find a way to mix one passion with another.

At our fire hall (http://www.langdonfire.ca) in Langdon AB we have been long waiting for the integration of technology into the fire service. For many reasons it has been a long wait.

I started out a long time ago with our web site, mentioned above, and hosted it on one of my Azure instances. It hosts some of our reports, pictures, member info and so on.

More recently the membership pushed for some sort of tool which would allow us to map the location of the incident we have to respond to. Mapping your route to the destination in a rural environment is a critical exercise as every second counts.

Recently we found out that we could receive messages from our 911 dispatch center in Calgary. These messages, contain basic information such as the address of the incident, the type of emergency, the map number and event number.

The application to build has a few simple requirements (to start with):

  • A TV / Monitor in the station should display the information as soon as the message is received from 911 dispatch,
  • The members should be notified of the emergency via email and/or SMS, this is in addition to the portable radio’s we carry around 24/7/365.
  • Mapping and routing from the station to the scene of the incident.

SignalR

Somewhere in August of last year I read a blog post of Scott Hanselman about the use of SignalR (Asynchronous scalable web applications with real-time persistent long-running connections with SignalR). I bookmarked it at the time and thought of it again when I started with this project.

In short, SignalR allows you to push messages from the server to the client.

Dashboard viewI use SignalR in this project to push the 911 dispatch message to the dashboard in the station, as well as display the confirmations from the responding or non responding members. This allows us to see how many resources are available to respond to the emergency.

SignalR is easy to add to your Visual Studio project using the nuGet package manager.

Note: don’t create a folder in your project called signalr to add your hubs or persistent connection classes to, this will cause some unexpected effects.

First Attempt

In the first version of the solution I just focused on getting things to work. I had four things to figure out;

  • Receiving an email from 911 Dispatch center and analyze this email as soon as it is received,
  • Sending an email to all members, if configured to do so,
  • Sending an SMS message to all members, if configured to do so,
  • Pushing the messages to the dashboard.

Although not rocket science, the one of the requirements is, not to do any polling, and getting the messages (email / SMS) out to the members as fast a possible.

Office 365, hosted Exchange

I settled on using my existing Office365 account to receive the 911 dispatch email. Using Exchange Web Services Managed API 1.2 you can make a connection to the Exchange server and wait for incoming email. The connection is dropped every few minutes which fires the OnDisconnect event. Using this event allows you to reconnect to the Exchange server and wait for email.

Sending SMS

The most direct method of notification would be sending an SMS. There are two methods of getting this done, the first one would be to send an email to the cell phone provider of which the local part is then the cell phone number and the domain name would be the service provider. The problem is that you are sending an email which goes through your own email account through the Internet, arrives at the cell phone provider in their email server, gets then routed to their sms gateway and then finally it arrives at your cell phone.

The second option is to use a SMS gateway. You make a direct connection to the sms gateway provider’s web service, send your message to just the phone number, it will then go through the gateway to the destination provider which then sends it to the cell phone. This is of course a little abbreviated as there are many more components at either end of the gateway involved but we have a more direct connection than when using email.

I settled on using SMSGateway.ca they offer a easy to use API, and they allow me to send many messages per second where other cheaper services would queue all the messages you are sending and then release each message at a one second interval, unless of course you would take a more costly premium package or buy into a short code.

Putting it all together

I just started of with a simple static class which handled everything and added the “Start” method in the Application_Start() event handler of the web site using the Application_Start event.

protected void Application_Start()
{
     ThreadPool.QueueUserWorkItem(FireDispatch.Start);
     AreaRegistration.RegisterAllAreas();
     RegisterRoutes(RouteTable.Routes);
}

This worked well enough to prove things out but it is not scalable enough, not that we expect a big load but to get the 99.99% 99.95% uptime we should have at least two Azure Instances running.

In part two I will discuss the scalable solution design.

 

Update: Cory Fowler indicated that guaranteed uptime under the Azure Compute SLA is 99.95% and not 99.99% as I had posted.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Post Navigation