Home › Administer

Emergency Services Branch Added to the Project

A new branch of the Open IMS Core for Emergency Services support development has been published. So far it contains two new entities: the Emergency-CSCF (E-CSCF) and the Location Retrieval Function (LRF). These two components are instances of SIP Express Router, just like the other CSCFs in the Open IMS Core. The implementation is based on TS 23.167, TS 24.229 and TS 29.228.

How it works

The P/I/S-CSCF implementations have been extended to identify emergency registrations (changes available also in the trunk). In case of such a registration, the I-CSCF will add an emergency flag in the Diameter User-Auth-Request so that the HSS will ignore roaming restrictions. The P-CSCF is also able to identify emergency calls and forwards the initial emergency INVITE requests to an E-CSCF from the same IMS domain. Then E-CSCF is in charge of discovering the appropriate Public Safety Answering Points (PSAP), for example the nearest police call center, and forwarding the emergency initial INVITE requests to it. The E-CSCF also maintains statistics of the emergency calls (e.g. dialog state, expiration interval, anonymous or not). Only SIP based PSAP are supported, currently. The callback session for registered callers is using the interface from the PSAP to the S-CSCF in the same way as for a normal call to the caller. For the moment the location query from the PSAP to the LRF is not implemented (the Le interface).

Emergency registration versus non-emergency registration

When an emergency call is about to be generated, the user can be in one of the following situations:

  1. the user is not roaming and has already performed a non-emergency registration: it can generate directly an emergency call
  2. the user is not registered: regardless of the roaming state, it must first do an emergency registration and then generate the emergency call
  3. the user is roaming and although it has performed a non-emergency registration it must first perform an emergency registration and them attempt an emergency call
  4. the user does not have enough credentials to authenticate: it will attempt a so called "anonymous emergency call".

In our case, the roaming state is considered when the domain of the user's SIP URI is different from the domain of the Open IMS Core.
In order to be recognized as being part of an emergency registration, a REGISTER request will contain in the Contact header a "sos" SIP URI parameter, as in the http://tools.ietf.org/html/draft-patel-ecrit-sos-parameter. For example:

Contact: "Alice" <sip:alice@example.com;sos>;q=0.7;expires=3600

The P-CSCF will reject all non-emergency calls performed using a contact registered for emergency purposes with a 403 (Forbidden) reply. If the P-CSCF does not support emergency services it will reply to an emergency REGISTER with 503 (Service Unavailable). This will be the same reply when the P-CSCF receives an anonymous emergency call and is configured to reject them. When the P-CSCF will receive an emergency call but the user is not compliant to any of the above use cases, it will send an 380 (Alternative Service) (see TS 24.229).

Recognizing emergency calls

An INVITE, PRACK, ACK, UPDATE, BYE or CANCEL request will be considered to be part of an emergency call if the request URI is one of the emergency services URNs defined in the RFC 5031. The P-CSCF of the Emergency Branch of Open IMS Core has also a flexible support for recognizing emergency numbers in the Request URI: an XML configuration file at the P-CSCF contains mappings between telephone numbers and their associated emergency URN, for example: 112 and "urn:service:sos.ambulance". The emergency numbers will be replaced by the URNs when forwarding the requests to the E-CSCF, so that the E-CSCF can have an uniform and meaningful input.

Emergency-CSCF (E-CSCF)

The emergency INVITE request will be forwarded from the P-CSCF to the E-CSCF. Using an OPTIONS request, the E-CSCF will interrogate the LRF about the appropriate PSAP URI by setting:

  • the request URI to the user URI. If the call is anonymous, the E-CSCF will set the request URI to "sip:anonymous@domain.org", so that the LRF can recognize it as such
  • the name of the service in a "Service" header field
  • the location information (if present) in the body

When a 2XX response code is received from the LRF, the E-CSCF will forward the emergency INVITE to the PSAP. In case an error response, the E-CSCF can be configured to use a Last Routing Option, meaning a default PSAP.

Before forwarding the INVITE, the E-CSCF will

  • replace the request URI and the To header field with the PSAP URI
  • add the ESQK header
  • if present in the reply, add the location information forwarded by the LRF

If no default PSAP is configured, an error response will be sent to the calling party. The E-CSCF stores the emergency dialog information, if no error occurs.

Location Retrieval Function (LRF) and Routing Determination Function (RDF)

The location information included in the initial INVITE request is considered to be "Location-by-value" as defined in the draft http://tools.ietf.org/html/draft-ietf-sip-location-conveyance. Both E-CSCF and LRF expect the geopriv PIDF location object format as described in RFC 5491, and the civic one as in RFC 5139. Otherwise a 424 (Bad Location Information) response will be sent to the calling party, from the E-CSCF.

In case the initial INVITE request does not include location information, the LRF can be configured to retrieve it from a LOCSIP server in a geopriv PIDF location object. The LOCSIP server comes from OMA Location in SIP/IP Core and is a protocol defined by Open Mobile Alliance (see here the specifications).

If the LRF receives location information either from the E-CSCF or the LOCSIP server, it can be configured to query a Routing Determination Function (RDF) for the appropriate PSAP URI. In our architecture a Lost server is acting as an RDF. Location to Service Translation Protocol (LoST) is a protocol that can be used to map location information and type of service to a URI (see here the description). In case the PSAP URI is determined, a 200 OK reply will be sent to the LRF, containing:

  • the PSAP URI in a "PSAP-URI" header
  • the allocated Emergency Service Query Key (ESQK) (see TS 23.167) in a "ESQK" header field
  • the location information retrieved from the LOCSIP server, if the case

Otherwise an error message will be sent to the E-CSCF. The LRF has also the role to store for every non anonymous calling party a set of information: the SIP URI, the last known location information, the name of the requested service (e.g. "urn:service:sos"), the PSAP SIP URI and the allocated ESQK.

Available Demos

After the first year of the PEACE project, in November 2009, the team has recorded demos for the various supported scenarios. For the caller the myMonster with enhancements for location retrieval, emergency calls recognition was deployed. For the PSAP the same client was used with enhancements for extracting the location information from a call and displaying the calling target on a map using Google Maps API and Google Geocoding Service for converting the civic location into the geodetic one. For the LOCSIP server the Global Location Enabler developed by the partner Telefonica I+D was deployed. You can watch the demo videos here.

How to configure and install

Please follow the steps from the installation guide of the emergency branch.

Testing

The documentation on how to generate sample emergency registrations and calls using SIPp scripts can be found in the testing guide.

Acknowledgement

One of the major development goals of the emergency support for IMS is to provide the research community in general and the European in specific with a powerful and extensible open-source framework allowing the placement of daily emergency calls. This framework is being developed under the umbrella of the IST funded project PEACE and the BMBF project MAMSplus.

Contact

For questions or issues related to Open IMS Core and the Emergency Services branch please use the General Discussion mailing list (aka user mailing list).

For further details on the NGN Emergency Services activities at Fraunhofer FOKUS or the PEACE project, please contact us here.