\documentclass[11pt]{article}
\usepackage{times,graphics,ifthen,i-d,html,txtpsfig,tight}
\usepackage[dvips]{changebar}

\title{SIP: Session Initiation Protocol -- Emergency Services}
\author{Schulzrinne/Costa-Requena}
\shorttitle{SIP}
\filename{ietf-schulzrinne-emergency-00}
\wg{SIP WG}
\expires{June 2001}
\address{Columbia U./Helsinki U.}
\pubdate{\today}
%\input{rfc}
\input{../defs}


\begin{document}
\maketitle
\begin{abstract}
\end{abstract}


This document describes a solution to be placed on the Session 
Initiation Protocol (SIP)(RFC 2543) [2] to enable emergency 
services.
It describes a new SIP method "EMERGENCY" for enabling emergency 
calls in VoIP. The EMERGENCY method facilitates the notification 
during an emergency situation and delivers the user location 
information uplink. It also provides the first aid instruction 
downlink in the body of the request.
The use of a common method allows the globalization of this 
essential service regardless the implementation of the service at 
any country.


2. Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
this document are to be interpreted as described in RFC-2119 [ ].



3. Emergency Requirements 

The Session Initiation Protocol (SIP)[3] as signaling protocol only 
provides call control. However, since it is text-based can be 
extended with other information inserted as SIP payload. Though, SIP 
is currently able to set up a single voice call and to carry (in the 
body) the information of more detailed multimedia session using SDP 
[4] protocol packet or any other similar protocol.

Some countries such as USA and EU have decided to make all emergency 
calls geographically locatable by law. IP Telephony is also required 
to support the emergency purposes such as E911 [5] call services in 
USA or 110 and 112 in Germany and Europe. These services in IP 
Telephony are required to be universally available regardless of the 
network where the user is registered and the device that he is 
using. Thus, it is recommended to define a SIP method for indicating 
the emergency reason for establishing this session. The new request 
MUST be mandatory and common understood at any SIP enabled network. 
Hence, the proposed EMERGENCY method will be used globally 
independently of the country or syntax used for the emergency 
service at any country.

4.	Message Requirements

Therefore, the SIP message MUST contain additional information for 
locating the user and unequivocally send to the right address the 
first-aid services. Furthermore, the motivation of this 
specification is to enhance SIP with the required spatial location 
capability for facilitating the mandatory emergency call services. 
Since the SIP protocol has the capabilities for providing user 
mobility it is well tailored for this purpose. The Spatial Location 
(SLO)[6] is a data set proposed for defining the geographical 
location of the user. Thus, SLO could be the data structure used for 
defining the user location. Hence, the information of the user can 
therefore be considered as session data to be carried in the SIP 
payload. 
In this case, SIP is used for establishing a complete session 
between two users with the highest priority providing the essential 
information for solving emergency situations. That information can 
be either the user location only (using SLO) in case of desperate 
situation or it can be added additional text information describing 
the problem. The former case happens when a problem suddenly occurs 
and the alarm needs to be activated just pressing a single button in 
the user's device.
The latter situation is set in an emergency situation when it needs 
to be set up a complete session for exchanging preliminary 
information meanwhile the first-aid services arrive to location 
where the problem occurs. 
This mechanism can even be used to create high priority sessions for 
medical purposes. This transaction will require to be processed with 
maximum priority and including the highest QoS for the media 
exchange.

5. SIP entities SLO enabled

The entities involved in a SIP session and specifically to provide 
the emergency service are User Agent, Proxy Server, Redirect Server, 
Registrar Server, Location Server, additional Positioning Function 
and the Emergency Authority.


* The Registrar server is a server that accepts the user registration 
(REGISTER message). The user information received within the SIP 
message at the Registrar server is extracted from the SIP message and 
it is forwarded to be stored at the Location server. The role of the 
SIP Register in an emergency service is to handle some concrete 
situations where the user needs to find out his geographical 
location. In the case that the user device does not have any 
positioning mechanism that information would be supplied during the 
registration. Thus, the SIP registrar MUST understand the meaning of 
carrying "SLO-data" in the "Content-Type" header. If the "SLO-data" 
is empty the SIP register MUST fill and send it back in the 200 
Response. The rest of the transaction is processed in a normal way 
for allowing backward compatibility.

* The Proxy server will receive the User Agent message and in case of 
EMERGENCY method it should process with the highest priority. 
Furthermore, it has to find out if the message includes the SLO data 
with the location information. In case the SLO-data is empty, the 
Proxy should fill it using a Positioning Function and finally deliver 
that information to the Emergency Authority using any specific 
transport defined by the EA. The SIP message can also carry SDP 
information to establish a session for exchanging some initial 
advises for the problematic situation. The Proxy will connect the UA 
directly with the EA for exchanging video or audio streams.

* The Location Server is an element used by a Redirect or Proxy 
server to obtain user information (including the spatial location of 
the callee, etc.). The Location server is a SIP entity, which is 
collocated within the Registrar server. Therefore, in this paper the 
Location Server is improved with the storage of spatial location 
information for emergency purposes. 


* The SIP User agent would be the element whose spatial location the 
emergency service requests. It may or may not have capabilities for 
resolving its location. In case of simplest equipment, it will send 
to its server the Spatial Location structure (SLO-data) without the 
geographical information. In this case the data structure includes 
the user requirements and basic information. Within that data is 
included the rights to the server for resolving the target location 
and filling the Spatial Location structure.
The User Agent can also receive an EMERGENCY method coming from the 
EA indicating any catastrophe happening close to the user location. 
Thus the UA MUST process that message and its payload in case it is 
carrying some instructions, picture or other relevant information.

* Positioning Function (PF) determines the spatial location of a 
given terminal. It can be an integral terminal function, e.g. based 
on GPS, Location Information Service (LIS) or Local Positioning 
System (LPS) provided by a Network Provider, e.g. based on radio cell 
information or a triangulation mechanism. It can be located at the 
target (SIP UA) or at the Location Server if the Target does not have 
this capability. Thus, if the user has not LPS functionality, he 
needs to access the network for obtaining that information. 

* The Emergency Authority (EA) MUST be a VoIP enabled server at least 
to establish a media session with the user in case of an emergency 
session needs to be established. The EA can receive a message from 
the SIP proxy with the user's location information and his device 
capabilities and IP address for setting a media session if necessary.



4.	Operation overview

There are different scenarios depending on the user capabilities and 
requirements. When the user device has no possibility of obtaining 
his location, then it needs to be assisted by the network elements. 
In this operation the user utilize the SIP Registrar for obtaining 
his spatial information. The user tries to register indicating that 
the content of the body is a SLO-data structure but it is empty and 
it needs to be filled by the Registrar or any additional entity.



 
        REGISTER         +-------------+ 
             <SLO/empty>      | Registrar   |
     User   ----------------> |             |                           
   (SIP UA)<----------------- | (SIP Proxy) |
            200 OK            +------------++ 
            <SLO/filled>        .     
                                .  +--------+     +------------+
                                ...|Location|.....|   Other    | 
                                   |Server  |     | Positioning| 
                                   +--------+     | mechanism  | 
                                                  +------------+ 
    
Figure 1: Example architecture using SIP Registrar for obtaining the 
SLO-data

This type of operation is not necessary when the user device has 
positioning capabilities.

In this case when the emergency situation occurs it used the new 
EMERGENCY method for notifying the situation. All the Proxy servers 
MUST understand this method and information on its payload should be 
addressed without any delay to the first aid authorities (EA).



 User                  SIP Server           Emergency 
(SIP UA)              (SIP Proxy) 	    Authority    
   user@example.com 	       home.net 
|                      |                     | 
        |                      |                     | 
        |                      |                     |
        |--------------------->|                     |    
   |EMERGENCY home.net    |                     |
   |Content-Type: SLO-data|                     |
   |<SLO-data>, <SDP>     |                     |
        |                      |                     | 
        |                      |-------------------->| 
        |                      |<SLO-data>,<user-SDP>|
        |                      |                     |
        |                      |                     | 
        |                      |<--------------------|
|                      | <EA-SDP>            |
|<---------------------|                     |
        | 200 OK <EA-SDP>      |                     |
|                      |                     | 
|--------------------->|                     |
|        ACK           |                     |
|                      |-------------------->|
|                      |         ACK         |
|<================EMERGENCY MEDIA===========>|
|                      |                     |

         Figure 2:  Example message flow for emergency situation



Another possibility is when the user registers and sends the SLO-
data in the SIP REGISTER, then if the "Expires" header is set to any 
value different from zero it means that the SLO data will remain in 
the SIP server (Location Server). 
This operation is depicted in the Figure 3, where in the first step 
the user provides his location information during the registration. 
In this case when the emergency situation occurs and the user device 
is unutilized the user can even be located using the old information 
provided during the registration despite it could be not up to date. 
The stored SLO-data information can also be used when any disaster 
occurs and the EA needs to broadcast important information to handle 
the situation to all the devices situated in the problematic area. 
This circumstance is shown in Figure 3.b.





Figure 3.a   REGISTER
<SLO/filled>     +-------------+ 
             Expires: 3660    | Registrar   |
     User   ----------------> |             |                           
   (SIP UA)<----------------- | (SIP Proxy) |
             200 OK           +------------++ 
                                .     
                                .  +--------+     +------------+
                                ...|Location|.....|   Other    | 
                                   |Server  |     | Positioning| 
                                   +--------+     | mechanism  | 
                                                  +------------+ 

Figure 3.b

        EMERGENCY             +-------------+  Notify +-----------+ 
       <first instructions>   | Registrar   |  Alert  |Emergency  |
  User  <-------------------- |             |Situation|Authorities|                  
(SIP UA) -------------------> | (SIP Proxy) |<--------|           |
           200 OK             +-------------+         +-----------+
                                     .     
                                     .  +--------+
                                     ...|Location| 
                                        |Server  | 
                                        +--------+ 

Figure 3:  Example message flow for emergency situation


5. Message Coding

The SIP headers are essential for identifying the Caller, the Callee 
and the reason or status of the transaction. The message body can 
contain any kind of data and its interpretation depends on the type 
of message. Generally, the content of the body can contain a session 
description following a specific format such as the Session 
Description Protocol (SDP), text or XML scripts. The "Content-Type" 
header field tells the media type of the message body. Hence, the 
"Content-Type" header can be extended for indicating the type of 
payload that the SIP message is carrying. Thus, in this proposal it 
will be utilized for indicating that the SIP body contains the SLO 
data. Figure-2 depicts an example of SIP messages where the Content-
Type header indicates the payload that is embedded in the message 
(SLO-data).




6. SIP and SLO data

The SLO is a location dataset for defining the spatial information 
discussed at the IETF spatial group. The components of the SLO data 
are depicted in Table-1.

Datum
- WGS84 (Mandatory)

Coordinates
- Latitude (Mandatory)
- Longitude  (Mandatory)
- Altitude above WGS84 reference ellipsoid (Optional)
- Altitude above mean sea level (Optional)


Location Accuracy
- Horizontal accuracy, by radius of a circle from the 
positioned point (Optional)
- Altitude accuracy, by range from the positioned point   
(Optional)

Time
- Real time of the measurement/fix (Mandatory)

Speed
- Ground speed (Optional)
- Vertical speed  (Optional)

Direction
- Direction of movement (Optional)

Course
- Direction from the current position to a defined 
destination 
Orientation (Optional)
- Horizontal orientation (Optional)
- Vertical orientation (pitch)

Un-specified Attributes 

- Attributes enabling some extensibility (Optional)

			Table 1. Components of the SLO dataset.




7. Representation Negotiation

SIP contains already specific methods (OPTIONS) for negotiating a 
common understanding for managing the payload. Later on, the body 
content of the SIP message is indicated in the "Content-Type" header. 
The IANA allows the registration of new types of contents and it 
would be indicated like "Content-Type: application/SLO-data". The 
SLO-enhanced SIP message includes the SLO payload. Thus, using the 
OPTIONS method the User Agent can discover the SIP server enabled 
with SLO capabilities.




8. Server Discovery

SIP provides already server discovery mechanism using pre-defined 
configuration or multicast queries to a DHCP server. Thus, the user 
terminal when starts up can obtain immediately the address of its 
closest SIP server. Another discovery feature also in the SIP 
protocol is to resolve the nearest SIP server address using the SRV 
records from DNS.
After discovered the SIP registrar, the User Agent can perform a SIP 
registration where it can use the SLO as payload. After the 
registration the SLO data is stored in a databases at the SIP 
Location server and from there the data can be extracted when it is 
relevant.
Furthermore, if the user sent the SLO structure with expiration time 
equal to zero after being returned the SLO data to the user there 
will not be any SLO data left in the Registrar. Thus, the user uses 
the registrar just for obtaining the information and for emergency 
purposes the SLO data will be required directly from the user.
Once the user has been registered and he obtained his spatial 
information it will be kept at his own device. In case of emergency 
situation the user just sends an EMERGENCY method with the SLO data 
that he already have placed in the body of the request.
This method obtains the maximum priority at the SIP server and its 
payload will be forwarded to the emergency services.

10. Security

Implemented by SIP and SLO provide additional security to the SLO 
data.

11. Policy

There is policy mechanism within the SLO data structure. It defines 
the user requirements for managing the content of SLO info at the SIP 
entities. Thus the user can strictly indicate that he wants to 
register his location information but it MUST be kept invisible 
unless it is required by the EA. The user can also indicate a 
restrictive use of that information for a list of users (family and 
close friends). Hence, the policy info is not yet specified in the 
SLO-data but it is necessary to be read/enforced by the SIP servers 
enabled with SLO-data.


13. References



3	M. Handley, H. Schulzrinne,  E. Schooler, and J. Rosenberg, SIP:        
   session initiation protocol," Request for Comments (Proposed  
   Standard) 2543, Internet Engineering Task Force, March 1999.

4	M. Handley and V. Jacobson, "SDP: session description protocol", 
RFC 2327. IETF, Aprl 1998

5	Reporting Deadline Phase II E911 ALI, CC Docket No. 94-102, 
   FEDERAL COMMUNICATIONS COMMISSION. http://www.fcc.gov

6	M. Korkea-aho, H. Tang, J.M. Polk, and K. Takahashi, " A Common 
   Spatial Location Dataset," draft-korkea-aho-spatial-dataset-  
   00.txt, Internet Draft, IETF, Nov. 2000.


11. Acknowledgments

<Add any acknowledgements>


12. Author's Addresses

Henning G. Schulzrinne
Columbia University

Jose Costa-Requena
Helsinki University of Technology




Full Copyright Statement

"Copyright (C) The Internet Society (date). All Rights Reserved. 
This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph 
are included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into




mailto:mikega@microsoft.com
   Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
9, RFC 2026, October 1996.

   Bradner, S., "Key words for use in RFCs to Indicate Requirement 
Levels", BCP 14, RFC 2119, March 1997




	Emergency Service Requirements for SIP	November 2000


 
Sip	Informational � Expires June, 2000	10
 
Sip	Informational � Expires June, 2000	1
