Providing Emergency Services in Internet Telephony

1. Providing Emergency Services in Internet Telephony Henning Schulzrinne and Knarig ArabshianDepartment of Computer ScienceColumbia University {hgs,knarig}@cs.columbia.edu February 25, 2003

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

3. 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

4. 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 e-mail) 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

5. 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.

6. 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 email-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.

7. 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.

8. 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.

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

10. Basic call setup • Phone sends INVITE; acts as User Agent Client • Server can proxy the call to current location INVITE sip:alice@m2.home.com … To: sip:alice@home.com From: “Bob” <sip:bob@office.com> … INVITE sip:alice@home.com … To: sip:alice@home.com From: “Bob” <sip:bob@office.com> … c=IN IP4 128.59.19.60 m=audio 8000 RTP/AVP 0 5 8 alice office.com m2.home.com bob home.com Proxy User agent client

11. 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 SIP/2.0 180 Ringing SIP/2.0 200 OK … c=IN IP4 135.180.144.32 m=audio 9000 RTP/AVP 0 8 office.com alice pc4.home.com m2.home.com bob home.com Proxy User agent server

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

13. Basic call setup • When either party hangs up BYE is sent office.com alice BYE sip:bob@office.com bob home.com

14. 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

15. 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

16. 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

17. 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

18. 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

19. SERVER (NOTIFIER) CLIENT (SUBSCRIBER) SUBSCRIBE sip:sos@leonia.nj.us SIP/2.0Event: emergencyExpires: 86400 From: sip:alice@example.comTo: sip:sos@leonia.nj.us SIP/2.0 202 Accepted From: sip:alice@example.comExpires: 86400 NOTIFY sip:sos@leonia.nj.us SIP/2.0Event: emergencyTo: sip:alice@example.comFrom: sip:sos@leonia.nj.us<soap:body> <m:emergency> <type>fire</type> <material>wood</material> <alarms>2</alarms> </m:emergency></soap>

20. 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.

21. 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

22. XML Schema <?xml version="1.0" ?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:complexType name="EmergencyType"> <xs:sequence> <xs:element name="Fire" type="Fire"/> <xs:element name="Earthquake" type="Earthquake"/> </xs:sequence> </xs:complexType> <xs:complexType name="Fire"> <xs:sequence> <xs:element name=“materials" type="string"/> <xs:element name=“alarms" type=“decimal"/></xs:sequence> </xs:complexType> <xs:complexType name="Earthquake"> <xs:sequence> <xs:element name="location" type="string"/> <xs:element name="scale" type="decimal"/> </xs:sequence> </xs:complexType> </xs:schema>

23. 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

24. 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

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

26. Detailed overview of architecture 3) Sipc contacts notification server and gets list of emergency events user can subscribe to 2) Generic emergency address: emergenycy@state.ny.us is added to sipc 1) Event generators publish their events to notification server Fire sos@leonia.nj.us Notification server (sipd) Earthquake 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 4) User subscribes to event it wants to be notified of

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

28. Example of Notification: Flashing of Lights • 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 lamp serial port DO sip:lamp@cs.columbia.edu SIP/2.0 ….. <Control> <Action>turn lamp on</Action> </Control> X10 device

29. Alerting Hierarchy United States Federal Govt. NJ State Govt. Alabama Alaska New Jersey Wisconsin Wyoming NOTIFY SUBSCRIBE Atlantic Bergen

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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 e-mail to them indicating • Their password is if they wanted to subscribe • Types of emergency notifications the server supports

36. 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

37. 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.

38. 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.

39. 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

40. Contacts • Knarig Arabshian (knarig@cs.columbia.edu) • Dr. Henning Schulzrinne (hgs@cs.columbia.edu)