multimedia conferences, Internet telephony calls, instant messaging and event notification. This paper will ... In particular, Reverse 911 [6] offers emer- ... specialized emergency monitoring centers or similar types of organizations. Thus, the ...
SIP-based Emergency Notification System Knarig Arabshian and Henning Schulzrinne Department of Computer Science Columbia University October 2001
Abstract We describe how the Session Initiation Protocol can be used to implement an emergency notification system. This system offers advantages such as portability, lower resource consumption, and an additional means of reaching people in case of an emergency.
1 Introduction Emergency notification systems allow government officials to notify a community of an emergency and the subsequent precautionary measures that must be taken. They provide a quick and efficient way of informing the public of an emergency situation and for insuring its safety. It is likely that traditional modes of communication will be augmented by Internet telephones and applications in the near future. Thus, we need to have emergency notification systems established on the the Internet. The Session Initiation Protocol (SIP) [1], which is an application-layer signaling protocol, has been used for maintaining sessions of Internet multimedia conferences, Internet telephony calls, instant messaging and event notification. This paper will discuss how an emergency notification system can be developed using SIP.
2 Overview of Current Emergency Notification Systems The Emergency Broadcast System (EBS) was developed in 1963 to notify the public of emergency situations. In December 1995, the Federal Communications Commission (FCC) changed the EBS to the Emergency Alert System (EAS). This change signified a different way state and local governments provide the emergency notification and instruction to the public. The EAS uses digital technology that functions similarly to computers. It automates the notification process and specifies the requirements of when and how to provide the emergency instruction to the public. Thus, the state and local governments can inform the public through radio, television and cable stations without the need for the broadcast industry to be present. The EAS can also transmit this information to a specific location in an emergency situation, as long as there have been predetermined arrangements of the communication links. The EAS is controlled by the government and used mostly for wide area emergency notification. However, there are emergency notification networks and products that offer emergency alerting in a localized 1
area. A few examples of these are given in [3], [4], [5] and [6]. In particular, Reverse 911 [6] offers emergency notification service to local officials or companies who can subscribe to the network and receive any emergency notifications that occur in the nearby vicinity. The subscription includes preferences regarding the geographical location of the notification, the types of emergency alerts, and the alert method, such as sounding off an alarm or siren, flashing lights, an instant message or telephone calls. The subscriber will provide a list of local phone numbers to the notification network, which will then monitor that location of any emergency situation it had registered for and notify it in case of an emergency.
3 SIP-based Emergency Notification System SIP can be extended to provide event notification [7]. SIP clients can subscribe to a remote SIP server and request notification from it. In the case of an event, the remote server will alert the client that an event has occurred. There are two main institutions that this system will deal with: a Subscriber and a Notifier. The Subscriber represents the institution that subscribes for emergency notification services. Conversely, the Notifier is the institution that issues notifications in case of emergencies. The following paragraphs will describe how SIP SUBSCRIBE/NOTIFY messages are sent between the Subscriber and the Notifier.
3.1 Subscribe/Notify Within the SIP architecture, the Subscriber subscribes to the Notifier indicating that it wants to be notified of certain events. An example of this might be when an official organization in a local community subscribes to certain emergency notification agencies. These agencies could be the local police department, specialized emergency monitoring centers or similar types of organizations. Thus, the Subscriber will send subscribe requests and receive event notifications and the Notifier will receive subscribe requests and send event notifications. The SIP message will have “SUBSCRIBE” or “NOTIFY” in the method section of the SIP request. A SUBSCRIBE message resembles that of the SIP INVITE. It will have a new Call-ID, “To” field which contains the URI of the header notifier, and “From” field which contains the URI of the Subscriber. The confirmation of a subscription will be sent by the Notifier in the form of a NOTIFY message. The SUBSCRIBE request must have one “Event” header in the Header field. This will specify the type of event that is being subscribed to. In the case that the Subscriber wants to subscribe to multiple events, it will send multiple SUBSCRIBE messages to the Notifier. An example of this is if a local community wants to be notified of emergency weather alerts and any chemical spills in the area by the local emergency monitoring station. It will send two SUBSCRIBE messages to the emergency monitoring station indicating its preferences. The SUBSCRIBE messages in this case will have two different Call-IDs, which will specify that they are two distinct subscriptions. There must be one “Contact” header, which will denote where NOTIFY requests should be sent to. The SUBSCRIBE message must also contain an “Expires” header which defines the duration of the subscription. If the Subscriber wants to refresh its subscription, it just sends another SUBSCRIBE message to the Notifier which will have the same Call-ID but a different CSeq number. Conversely, if it wants to unsubscribe, it sends a SUBSCRIBE message with the “Expires” field set to zero.
2
There is an optional message body of the SUBSCRIBE request, which can signify further details of notification. In this case, if a message body is present, then it should have a standardized grammar to automate the processing of the subscribe request in the Notifier. Thus various fields of the message could indicate preferences such as: method of alerting (e.g. sirens, IM message, telephone call), additional instructions for evacuation procedures and precautionary measures. If the message body is not present then the subscriber will expect the default emergency notification procedure sent to it. Once the SUBSCRIBE request has reached the Notifier, it will be processed and put in a database. The “Event” header must be checked to see if the Subscriber has subscribed to valid emergency events. The Notifier should also authenticate the message received to assure that it is from a certified local community official or related organization. Once it determines that the subscription message is valid, it sends a confirmation NOTIFY containing the same Call-ID, local URI and remote URI that the SUBSCRIBE request had ordered. Otherwise, a message to the Subscriber is sent indicating an error. In the case of an emergency, the Notifier will send a NOTIFY message to the Subscriber. As mentioned above, the “Event” header will indicate the type of emergency that it is notifying. It must also contain a “Contact” header, which will allow the Subscriber to construct “Route” headers for further subscriptions. If there is no response from the Subscriber or an error message is received, the Notifier will remove that particular contact from the subscription list and send an alert to another contact within the same subscription. If all contacts fail, then the subscription is removed from the database. As in the SUBSCRIBE message, an optional body could be included which indicates the details of the emergency situation and the precautionary measures that must be taken. Figure 1 shows the SUBSCRIBE/NOTIFY message flow during an emergency notification.
3.2 SIP Authentication Authentication of the parties in question is a vital part of this system. In our application, the Notifier needs to verify that the Subscriber subscribing to it is an authorized official capable of handling emergency notifications. Similarly, the Subscriber must authenticate the veracity of the emergency alerts sent by the Notifier to prevent false alarms from occurring. SIP provides authentication of messages similar to that of HTTP. When a SUBSCRIBE message is sent to the Notifier, the Notifier responds with a 401 message, containing a “WWW-Authenticate” header, which challenges the authorization of the Subscriber. The Subscriber then responds with an “Authorization” header which includes an encrypted message including its username and password. Likewise, in the event of an emergency when the Subscriber gets alerted with a NOTIFY message, it challenges the authorization of the Notifier. There are two authentication schemes used: basic and digest. The basic authentication has weak security since the username and password is transmitted onto the network in plain sight. Thus, digest authentication is a better choice since it uses a few more name-value pairs besides the username and password and via cryptographic hashes, determines the authenticity of the Subscriber. A Subscriber needs to be aware of all the local emergency alerting agencies in its area. Below, we describe several different ways of setting the system up so that the Subscriber will obtain a password to log into the server maintained by the Notifier.
3
3.2.1
Third party provides credentials
In this scheme, a third party operates a directory server with all the relevant information of the local area. It maps Subscribers to local Notifiers. The directory server should be monitored and maintained by government officials who recognize these subscribers as valid institutions, such as local police, fire departments or government agencies. The Subscribers and Notifiers should subscribe to the local directory server and signify the various emergency alerts they request or support and details of that nature. There is an optional header named “Allowed-Events”, which when specified by either the Subscriber or the Notifier, indicates the list of event packages supported by it. Thus, in this case, an emergency notification server could notify the directory server of the different emergency alerts it supports by putting these in the “Allow-Events” header. Similarly, the agencies requesting notification could specify the emergency alerts they want to be notified for by providing them in the “Allow-Events” header. The Lightweight Directory Access Protocol (LDAP) [7] could be used to obtain this information from the local directory server. The directory server is maintained by government officials who have certified the Subscribers and Notifiers as valid institutions capable of requesting and providing emergency notification to the public. Thus, the authorized passwords are established by these government officials, who manage the directory server, and distribute them to the local agencies. This could be done through certificates that the government officials provide to both the local Subscribers and Notifiers authorizing them as valid institutions. An extension to this is to not only provide certificates to an institution, but to individual employees within the institution. Thus, a person within an official agency who wants to subscribe to an emergency notification server, must be a certified employee and be authenticated by the notification server. Although this method is scalable and works well for a large number of Subscribers and Notifiers as well as individual employees, it is not the preferred method for this system. In reality, there are only a limited number of agencies within a community who are authorized by the government to provide and receive emergency notification. Thus, using a separate directory server for providing authentication is not desirable as it needlessly complicates the system. 3.2.2
Emergency Notification Server Provides Credentials
A better method for this system is if each emergency notification server had a pre-established list of the authorized government officials in its area. It then sends a password to them, either through the postal mail or encrypted e-mail, indicating what their password is if they wanted to subscribe to the notification server. The information could also contain the types of emergency notifications the server supports. Once the official agency receives this information, it can subscribe directly to the emergency notification server, by-passing the third party. When the subscriber sends a SUBSCRIBE message to the Notifier, it will receive a 401 WWW-Authenticate message in response. The Subscriber will respond with its encrypted password in the Authorization header. Once the Notifier receives the password, it checks to see if it matched the data in its database of plausible users. If it did, it would add the Subscriber as a registered user to its database and respond with a confirmation NOTIFY message. When the Subscriber receives the NOTIFY message confirming its subscription, it also adds the Notifier to its database of emergency notification servers that it could receive notification from. This can be seen in Figure 2. The emergency notification servers could renew the passwords of its subscribers periodically to insure 4
security. As stated above, the “Allow-Events” header could be used by both the Subscriber and Notifier. This indicates the types of emergency alerts they request or are capable of handling.
3.3 Network Architecture A hierarchical network structure is ideal for a SIP-based emergency notification system. This provides good scalability and facilitate the breakdown of the hierarchy by geographical location. A main emergency notification server at the root serves all the states in the USA. Then, each state has a server that serves its cities. Further down, each city serves its local counties and so on. Within the hierarchical tree, children of the same parent should also have directory listings of each other. Thus, on the sibling level, there is a peer to peer networking. In this particular case, such a design is beneficial because the number of government officials within a community will not be very high. Therefore, if a government official wanted to contact its sibling, it wouldn’t have to go through its parent, but rather could do a quick lookup in its database and send a message directly to its sibling. This saves time and resources in a critical emergency situation. Figure 3 shows such a hierarchy. The directory listing maintained by each server should map each server to an IP address. The server names are stored in a database using their geographical location names as keys. Thus, if the President wanted to alert the whole nation of an emergency situation, he contacts the root server which forwards the NOTIFY message to all of the 50 states and the message goes down the tree to every localized community in the United States. Another example this is useful for is if one city wants to notify another city of an emergency. If someone in Manhattan, NY was aware of an attack in Abbeville, Al and wasn’t sure of its exact location or URI, it forwards the NOTIFY message to the NY state server. The NY state server then forwards it to its sibling Alabama and then the message is forwarded down the tree to Abbeville, Alabama. This type of message flow is seen in Figure 4. It is necessary for all the child nodes to subscribe to their parent node servers and for all siblings to subscribe to each other. Government officials, who are aware of the different laws and regulations during an emergency situation, should govern the sending of all these subscriptions to the corresponding servers.
4 Open Issues There are a few unresolved issues in this design. A problem arises when, instead of the emergency notification server first contacting the subscriber and establishing authentication, the subscriber wants to find a local emergency notification server and subscribe to it. In order for this to occur, the subscriber needs to know its geographical location and somehow map it to locations of the nearest emergency notification servers. The SIP redirect server could be used for this purpose [1]. However, the redirect server accepts SIP requests and maps the SIP address in the INVITE header to one ore more SIP addresses and sends it back to the client. Since there is currently no way of mapping IP addresses to geographical locations, this could be modified so that the subscriber sends his postal zipcode to the redirect server, which responds with a list of emergency notification servers located in or near that zipcode. This would require the emergency notification servers to register their postal addresses with the local redirect servers.
5
5 Benefits in using SIP for Emergency Notification There are many reasons why SIP is a better choice than using the existing loud speakers or reverse 911 method for an Emergency Notification System. It can be deployed on the national level, similar to the EAS, as well as on the local level. The fact that SIP is a simple signaling protocol that runs over UDP, gives an added advantage in terms of speed and efficiency. The following are reasons why using SIP is more profitable over the other technologies mentioned in Section 2.
5.1 Use on Different Applications and Devices SIP can be applied to a broad range of applications such as: Internet telephony, multimedia applications, instant messaging and others. This type of flexibility is a great asset to an emergency notification system which might need different modes of communication in specific emergency situations–especially for those with disabilities. Since SIP can be used for automating the management of appliances, a notify message can induce lights to flash during an emergency which alerts the hearing-impaired. SIP can also be used on different devices such as 3G cell phones, PDAs, home PCs, and telephones. There is research being done to combine the Wireless Application Protocol (WAP) with SIP [11]. This will enable a SIP message to signal hand-held devices which are gaining greater momentum in today’s technological market. Thus, SIP will allow different devices to communicate with each other, using various applications, resulting in greater diversity in emergency notification.
5.2 More Information A SIP message can carry a lot of information. If it is a voice or text message, there could be a detailed description of the emergency event. Also, SIP enables multi-lingual content. Thus, a single message automatically generates voice or text in multiple languages and the receiver of the message can then use the language of his choice.
5.3 Automated Action The Subscriber can subscribe to the Notifier with its specific notification preferences: what type of emergency situation it wants to be notified for and the alert methods. For example, a Subscriber subscribes to the Notifier with the following preferences: fire, sound alarm bells. Thus, when a fire occurs, the Notifier will notify the Subscriber regarding the fire and inform the Subscriber to sound alarm bells. This can be done via the NOTIFY message body which contains information pertaining to the emergency at hand. The body is encoded in a certain way that informs the Subscriber of the specific alert activation. The Subscriber then processes the message body and automatically activates the specific alerts. This greatly increases the speed and efficiency of the notification process.
5.4 Lower Resource Consumption SIP will be running over the Internet, which is a much faster medium than PSTN. A one minute alert call approximately consumes 480 bytes of data one way. However, a SIP alert notification would consume at
6
most a few hundred bytes. Thus, the same bandwidth can reach as many as 1,000 times more people in the same time period. Also, due to the large amounts of bandwidth, it is easier to provide web hosting and other types of services.
5.5 Complementary to Current EBS System Although SIP is an Internet-based system, it would not interfere with the current EBS system, but instead complement it. As the system exists today, emergency broadcasts are done via radio and television. This could be integrated with the SIP-based emergency system to provide emergency notifications via the Internet as well.
6 Conclusion As the popularity of IP telephony and Internet communication increases in today’s society, the necessity of providing an emergency notification system on the Internet is becoming evident. Using current Internet technology, it is possible to create an implementation of the emergency notification system with SIP SUBSCRIBE and NOTIFY messages. Although there are still challenges in the area of location resolution, the fact that it can be deployed in addition to the existing systems, clearly makes it the preferable choice.
7
1) Send NOTIFY alert to the Subscriber
Subscriber
Notifier
2) Send 200 confirmation response to Notifier
Figure 1: Emergency Alert Notification
3) Subscriber sends an encrypted concatenation of its username and password in the Authorization to the Notifier
1) Susbscriber sends a SUBSCRIBE message to the Notifier Notifier
Subscriber 2) Notifier responds with a WWW−Authenticate message
4) Notifier confirms with a NOTIFY response message
Figure 2: Message Flow of SUBSCRIBE/NOTIFY Authentication
8
USA
AL
Abbeville
AK
AZ
AR
Montgomery
Figure 3: Hierarchy of Emergency Notification Servers in the United States NOTIFY NY
AL
NOTIFY
NOTIFY
Abbeyville
Manhattan
Figure 4: Message flow of an emergency notification from one city to another
9
WY
References [1]
M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, “SIP: Session Initiation Protocol“ Request for Comments 2543, Internet Engineering Task Force, May 2001
[2]
“FEMA: Background on the Emergency notification System (EAS).” http://www.fema.gov/pte/rep/easrep.htm
[3]
“Sam Emergency notificationing System” http://www.longboatkey.org/Departments/police/sam.htm
[4]
“Intelligent Wireless Solutions—outsourcing the emergency notification process.” http://www.inwireless.com/
[5]
“Community notification Network—High Speed Telephone Emergency Notification Service” http://www.can-intl.com/home.html
[6]
“Reverse 911 Interactive Community Notification” http://www.reverse911.com
[7]
A. Roach, “SIP-Specific Event Notification”, Internet Draft, Internet Engineering Task Force, July 2001.
[8]
W. Yeong, T. Howes, and S. Kille, ”Lightweight directory access protocol,” Request for Comments 1777, Internet Engineering Task Force, Mar. 1995
[9]
C. Davis, P. Vixie, T. Goodwin, and I. Dickinson, ”A means for expressing location information in the domain name system,” Request for Comments 1876, Internet Engineering Task Force, Jan. 1996.
[10]
A. Costanzo, “Definition of the DNS GL resource record used to encode geographic locations,” Internet Draft, Internet Engineering Task Force
[11]
The SIP Center–SIP and WAP (Wireless Access Protocol) http://www.sipcenter.com/aboutsip/sipmobil/wapsip.htm
10
