Providing Emergency Services in Internet Telephony Henning Schulzrinne and Knarig Arabshian Department of Computer Science Columbia University February 25, 2003

Overview Basics of SIP (Session Initiation Protocol) Emergency notification using SIP Details of notification architecture Benefits Conclusions

Using SIP for Emergency Notification It is likely that traditional modes of communication will be augmented by Internet telephones and applications in the near future We need to have Emergency Notification Systems established on the Internet

What is SIP? The Session Initiation Protocol (SIP) is a signaling protocol used for establishing sessions in an IP network. SIP is part of the IETF standards and is modeled upon other Internet protocols such as SMTP (Simple Mail Transfer Protocol for ) and HTTP (Hypertext Transfer Protocol for www) SIP is also being used in Microsoft Messenger in Windows XP A session could be a simple two-way telephone call or it could be a collaborative multi-media conference session. Different services are possible Internet telephony Instant Messaging with buddy lists Event notification Device control

What is SIP? Two Components within SIP: User Agent and the SIP Network Server. User Agent is the end system component for the call The User agent can be both a User Agent Client (UAC) and a User Agent Server (UAS) The client element initiates the calls and the server element answers the calls. SIP Server is the network device that handles the signaling associated with multiple calls.

What is SIP? Main function of the SIP servers is to provide name resolution and user location Caller is unlikely to know the IP address or host name of the called party since the caller will dial a an -like address or a telephone number associated with the called party. A SIP proxy server receives requests, determines where to send these, and passes them onto the next server (using next hop routing principals). The SIP Server component has three forms: the SIP stateful proxy server, the SIP stateless proxy server and the SIP re-direct server.

What is SIP? Difference between a stateful and stateless proxy server: stateful proxy server remembers the incoming requests it receives, along with the responses it sends back and the outgoing requests it sends on. It can fork requests to try multiple user locations and then send the best response back (call is received at multiple places) A stateless proxy server forgets all information once it has sent on a request.. Stateless Proxy servers are most likely to be the fast, backbone of the SIP infrastructure Stateful proxy servers are probably the local devices close to the User Agents, controlling domains of users and becoming the prime platform for the application services.

What is SIP? A re-direct server receives requests, but instead of passing these onto the next server it responds to the caller indicating the address for the called user. The caller then contacts the callee at the next server directly.

home.com office.com alice bob m2.home.com Basic call setup like identifier: Alice’s phone registers with home.com Bob dials Phone does DNS Registrar => REGISTER home.com SIP/2.0 To: Contact: … DNS lookup sip.udp.home.com Resolve to pc4.home.com pc4.home.com

home.com office.com alice bob m2.home.com Basic call setup Phone sends INVITE; acts as User Agent Client Server can proxy the call to current location INVITE … To: From: “Bob” … c=IN IP m=audio 8000 RTP/AVP User agent client INVITE … To: From: “Bob” … Proxy

home.com office.com alice bob m2.home.com Basic call setup Alice’s phone rings; acts as a User Agent Server When Alice picks up, call is accepted and bob’s phone sends ACK to complete the setup pc4.home.com SIP/ Ringing Proxy User agent server SIP/ OK … c=IN IP m=audio 9000 RTP/AVP 0 8

home.com office.com alice bob Basic call setup Encoded audio packets sent over RTP

home.com office.com alice bob Basic call setup When either party hangs up BYE is sent BYE

SIP-based Emergency Notification Besides VoIP, SIP also supports SUBSCRIBE/NOTIFY methods for event notifications Clients will subscribe to servers for emergency notification Servers will notify clients of particular emergency situation

Subscribe/Notify SIP message will have “SUBSCRIBE or “NOTIFY” in the method section of the SIP request. The SUBSCRIBE request Resembles that of a SIP INVITE Must have one “Event” header in the header field which will specify the type of event it is subscribing to. Must also contain an “Expires” header which defines the duration of the subscription

Subscribe/Notify If the Subscriber wants to subscribe to multiple events, then it must send multiple SUBSCRIBE messages, with distinct Call-IDs, to the Notifier and indicate each Event it is subscribing to If the Subscription has expired, then it sends another SUBSCRIBE message To unsubscribe, it sends a SUBSCRIBE message with the ”Expires” field set to zero

Subscribe/Notify Can contain optional message body in SUBSCRIBE request Further details of notification such as methods of alerting ( sirens, IM Messages, telephone calls) Standardized grammar to automate the processing of the SUBSCRIBE request in the Notification Server If message body is not present then Subscriber will expect the default method of alert

Subscribe/Notify NOTIFY Message Request The “Event” header will indicate the type of emergency notification it is The message body of the NOTIFY message will include specific instructions on the alert methods In our implementation, we use SOAP (Simple Object Access Protocol) for remote procedure calls

CLIENT (SUBSCRIBER) SUBSCRIBE SIP/2.0 Event: emergency Expires: From: To: SERVER (NOTIFIER) SIP/ Accepted From: Expires: NOTIFY SIP/2.0 Event: emergency To: From: fire wood 2

What is SOAP (Simple Object Access Protocol) ? Lightweight XML-based protocol used for exchange of messages in a decentralized, distributed environment Facilitates interoperability in a platform- independent manner Used for Remote Procedure Calls W3C note defines the use of SOAP with XML as payload and HTTP as transport, but other transport protocols can be used such as SMTP and SIP.

SOAP and SIP Emergency Notification Send a NOTIFY message with SOAP payload Body of the SOAP message will invoke a remote procedure relevant to the particular emergency event Use XML Schema to specify different emergency events handled and parameters needed

XML Schema

Why Soap? SOAP is a scalable and widely used wiring protocol Can use XML Schemas to configure notification parameters Although still not an industry standard and needs fine-tuning, using SIP and SOAP for emergency notification is simple and effective Wide remote system interoperability

Columbia SIP user agent (sipc) Media Audio, video, text, white board Screen sharing Shared web browsing Advanced Presence, instant messaging Conference control Emergency notification and handling Device control

Columbia SIP user agent (sipc) Calls 911 by connecting to the local PSAP Receive emergency notification alerts from various event servers that user has subscribed to Invoke Emergency Services

Detailed overview of architecture 2) Generic emergency address: is added to sipc Fire Earthquake Notification server (sipd) 3) Sipc contacts notification server and gets list of emergency events user can subscribe to 4) User subscribes to event it wants to be notified of 1) Event generators publish their events to notification server 5) Sipc gets XML schema reference from notification server that will generate a form which queries for the event’s properties. Sipc then updates its subscription to the notification server with the filtered expressions

Detailed overview of architecture 3)Sipc will process SOAP body and invoke the procedure call—such as flashing of lights Fire Earthquake Notification server (sipd) 2) Sipd will process parameters of the fire and send a NOTIFY to sipc including SOAP body 1) Fire occurs and event generator notifies sipd

Example of Notification: Flashing of Lights serial port lamp X10 device Emergency event notification invokes multiple calls of the SIP “DO” method This causes the lamp (connected to the PC by an X10 device) to flash DO SIP/2.0 ….. turn lamp on

Alerting Hierarchy United States Federal Govt. AlabamaAlaska New Jersey WisconsinWyoming NJ State Govt. AtlanticBergen NOTIFY SUBSCRIBE

SIP Authentication Notifier must verify that Subscriber is an authorized official capable of handling emergency alerts Subscriber must also authenticate the veracity of the emergency alerts sent by the Notifier to prevent false alarms

SIP Authentication Subscriber must be aware of all the local emergency alerting agencies in its area Someone has to provide this information Third party Emergency notification server

Third Party Provides Credentials Third party operates directory server with information about a local area Monitored and maintained by government officials who recognize Notification Servers and Subscribers as valid institutions Subsribers and Notifiers subscribe to the directory server indicating alerts they request or support Maps Subscribers to local Notifiers

Third Party Provides Credentials Lightweight Directory Access Protocol (LDAP) can be used to obtain information from local directory server Government officials managing the directory server Provide certificates to local Subsribers and Notifiers which establish them as valid institutions for community alerting Create and distribute passwords to the Subscribers and their matching Notifiers

Third Party Provides Credentials This method is scalable and works well for large number of Subscribers and Notifiers Not the preferred method for this system since there are only a limited number of agencies within a community who are authorized by the government to provide and receive emergency notification Separate directory server needlessly complicates the system

Emergency Notification Server Provides Credentials Each emergency notification server has a pre-established list of authorized government officials in its area It sends either postal mail or encrypted to them indicating Their password is if they wanted to subscribe Types of emergency notifications the server supports

Benefits Device Neutrality There are likely to be range of SIP-based end systems, ranging from IP telephones, 3G wireless handsets, IM/presence software to embedded devices. Thus, the emergency alert system can migrate to new devices, without having to explicitly be extended to handle them. More Information and Automated Action Video conferencing, text messaging Device control which causes flashing lights and aides the hearing-impaired

Benefits Lower resource consumption A one-minute alert call consumes about 480 kbytes (one way), while an alert notification is likely to be at most a few hundred bytes long. The same bandwidth can reach approximately1,000 times as many people in the same time period. Integration with current systems It would be straightforward to feed EAS (Emergency Alert System) and EDIS (emergency digital information system) into the SIP emergency alert system.

Benefits Out-of-area notification Current notification systems assume that only those in close physical proximity of the emergency event need to know about the event. SIP-based systems address cases where the recipient of the information is currently away, but still needs to be alerted. Examples: owners of summer cottages need to be aware of impending storms so that they can summon appropriate assistance or have their property checked on. Those at work may need to know about conditions affecting their home.

Conclusion and Future Work SIP gives opportunity to enhance existing emergency services by creating more functional, robust and flexible systems Next generation devices will be interoperable with SIP Using SIP SUBSCRIBE/NOTIFY messages we can develop an Internet-based emergency notification system Future/Ongoing work includes extending sipc features: Creating an E-911 system Creating a generic event notification server

Contacts Knarig Arabshian Dr. Henning Schulzrinne