Providing Emergency Services in Internet Telephony

1
Providing Emergency Services in Internet Telephony

• Henning Schulzrinne and Knarig ArabshianDepartmen
  t of Computer ScienceColumbia University
• hgs,knarig_at_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 ltsipalice_at_home.comgt
• Alices phone registers with home.com
• Bob dials alice_at_home.com Phone does DNS

REGISTER home.com SIP/2.0 To sipalice_at_home.com C
ontact sipalice_at_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_at_home.com gt alice_at_m2.home.com
10
Basic call setup

• Phone sends INVITE acts as User Agent Client
• Server can proxy the call to current location

INVITE sipalice_at_m2.home.com To
sipalice_at_home.com From Bob ltsipbob_at_office.com
gt
INVITE sipalice_at_home.com To
sipalice_at_home.com From Bob ltsipbob_at_office.com
gt cIN IP4 128.59.19.60 maudio 8000 RTP/AVP 0
5 8
alice
office.com
m2.home.com
bob
home.com
Proxy
User agent client
11
Basic call setup

• Alices phone rings acts as a User Agent Server
• When Alice picks up, call is accepted and bobs
  phone sends ACK to complete the setup

SIP/2.0 180 Ringing
SIP/2.0 200 OK cIN IP4 135.180.144.32 maudio
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 sipbob_at_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 sipsos_at_leonia.nj.us SIP/2.0Event
emergencyExpires 86400 From
sipalice_at_example.comTo sipsos_at_leonia.nj.us
SIP/2.0 202 Accepted From sipalice_at_example.com
Expires 86400
NOTIFY sipsos_at_leonia.nj.us SIP/2.0Event
emergencyTo sipalice_at_example.comFrom
sipsos_at_leonia.nj.usltsoapbodygt ltmemergencygt
lttypegtfirelt/typegt
ltmaterialgtwoodlt/materialgt
ltalarmsgt2lt/alarmsgt lt/memergencygtlt/soapgt
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

• lt?xml version"1.0" ?gtltxsschema
  xmlnsxs"http//www.w3.org/2001/XMLSchema"gt
• ltxscomplexType name"EmergencyType"gt
• ltxssequencegt
• ltxselement name"Fire" type"Fire"/gt
• ltxselement name"Earthquake"
  type"Earthquake"/gt
• lt/xssequencegt
• lt/xscomplexTypegt
• ltxscomplexType name"Fire"gt
• ltxssequencegt
• ltxselement namematerials" type"string"/gt
• ltxselement namealarms" typedecimal"/gtlt/
  xssequencegt
• lt/xscomplexTypegt
• ltxscomplexType name"Earthquake"gt
• ltxssequencegt
• ltxselement name"location" type"string"/gt
• ltxselement name"scale" type"decimal"/gt
• lt/xssequencegt
• lt/xscomplexTypegt
• lt/xsschemagt

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_at_state.ny.
us is added to sipc
1) Event generators publish their events to
notification server
Fire
sos_at_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 events 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 callsuch 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_at_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 siplamp_at_cs.columbia.edu SIP/2.0 .. ltControlgt
ltActiongtturn lamp onlt/Actiongt lt/Controlgt
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_at_cs.columbia.edu)
• Dr. Henning Schulzrinne (hgs_at_cs.columbia.edu)