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 situa- tions. In December 1995, the Federal Communications Commission (FCC) changed the EBS to the Emer- gency 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 sim- ilarly 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. How- ever, 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 emer- gency 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 sub- scribes 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 no- tification. 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 confir- mation 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 notifi- cations. 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, contain- ing 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 govern- ment 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.