From openSIPS

Documentation: Tutorials-Emergency-2-4

Documentation -> Tutorials -> Emergency Calls using OpenSIPS

This page has been visited 730 times.

Table of Content (hide)

  1. 1. Tutorial Overview
  2. 2. Problem
  3. 3. Solution
  4. 4. NENA i2 architecture
    1. 4.1 Components
    2. 4.2 Scenarios
  5. 5. OpenSIPS
    1. 5.1 Call Server in the scenario I or as the Routing Server in scenario II
    2. 5.2 Call Server in the scenario II
    3. 5.3 Call Server in the scenario III
    4. 5.4 Redirect Server in the scenario III
  6. 6. Configuration Example
  7. 7. References

Authors

1.  Tutorial Overview

The emergency module provides emergency call treatment for OpenSIPS, following the architecture i2 specification of the american entity NENA(National Emergency Number Association). This tutorial presents the i2 architecture, as well as the steps you need to follow in order to integrate emergency calls in OpenSIPS script.

2.  Problem

Until recently it was not possible to make a VoIP call to an unified emergency number of a particular country (911 in US or 112 in Europe). The difficulty is precisely in flexibility that the user has to originate a call anywhere in the world where you have access to Internet. As a result of this flexibility, the location information of the user is not known on a VoIP call.

The location is central to an emergency call for two reasons: to be able to route the call to the PSAP(call center responsible for answering emergency calls) nearest to where the call occurs, and so the attendants can send help to the scene.

In conventional telephony, routing is easily done by knowing the switch of the subscriber, and using the callback number, that is transmitted along with the signalling, the operator has the address relation for service. In cellular routing is performed considering the location of the radio base station serving the mobile device, and through methods of obtaining the location of the mobile device (such as Triangulation) location information can be obtained by using an architecture specifies attendant to this purpose.

The need for an emergency call beyond the obvious aspect of the rescue VoIP user, you can also find other aspects, for example, regulatory agencies of a country that establishes the realization of an emergency call as one of the minimum requirements to be met by this technology to be able to regulate it. Meet this regulatory aspect is important to that these agencies recognize VoIP as an alternative to conventional telephony and thereby grant VSP operators a numbering plan specific to VoIP, fundamental condition to the growth this technology in market.

Besides these aspects, we must also consider the gain of resources to conduct an emergency call on a VoIP environment entirely, as the ease of integration of the call to the monitoring system call. Another example would be to use the video feature, the PSAP attendant to assess the status of the event and be able to guide someone on site already provide first aid to the victim, optimizing the provision of relief.

3.  Solution

The IETF formed a working group to study the emergency call to the IP network, numerous RFCs came to this topic. They created the concept of LIS (Location Information Server), responsible for storing location information of a given target using the precepts of Geopriv[15]. The LIS should be housed in the ISP (Internet Service Provider) that provides Internet access to the device and can provide caller location information in two ways:

To transport and store the new parameters that are required to perform an emergency call, several protocols have to be adapted, including SIP who added new headers and new types of content, as well as new protocols were created, like HELD. Were considered for transport protocols both binary format (DHCP), such as using text-based XML (HTTP, SIP).

They also created Lost Server[6], a server used to determine the routing of the call depending on the location of the caller. Lost would be part of the architecture of the VSP (VoIP Service Provider).

The IETF has produced an architecture involving all these created or altered[13] elements. We will not detail this architecture, since our focus is in architecture specified by NENA that has a stronger purpose for OpenSIPS as discussed below.

4.  NENA i2 architecture

The NENA (National Emergency Number Association) is a group comprised of the Emergency Service American community. This group discussed and proposed technical and operational solution for emergency call over the IP network to American coverage.

The architecture proposed by this group is heavily based on concepts and protocols defined by IETF for emergency call. However there are differences in the two proposed architectures. The role of the endpoint in NENA architecture decreases with respect to the routing of the call, which happens to be a function of the VSP Call Server. The endpoint is limited to identifying the emergency call that in the American case is limited to 911, and get your location.

Another point is that the architecture of the IETF, considered the PSAP also attend a SIP call. The NENA preferred split into two phases: the first NENA i2, considering the legacy PSAP (in PSTN network), and a later stage NENA i3, which provides the PSAP in an exclusive emergency IP network.

4.1  Components

The components of this architecture shown in figure below:

4.2  Scenarios

From the business viewpoint, several scenarios can be discerned in this architecture:

Scenario I

Call Server of caller VSP takes over the treatment of the emergency call. The VSP is also the provider (source) that interfaces with the VPC. The scenario uses the following operating sketch:

Below are the steps to be followed to make an emergency call:

  1. The caller device receives its location by sending a query to the LIS - it can use the HELD protocol for this purpose. It gets this information by value (Location Object - LO) or by reference (Key Location - LK).
  2. The endpoint starts an emergency call by sending an INVITE to the Call Server with a R-URI: 911@sourcedomain, location information is included in this package: in Geolocation header(by reference) or in body with the application/pidf content, and callback number in the From header.
  3. The Call Server stores the callback number and associates it with the name of the subscriber. He requests the routing information to the call by sending to VPC the following data: caller number, subscriber identity, location information (LO or LK)
  4. If the location information was passed by reference (LK), the VPC will get the value(LO) with the LIS.
  5. The VPC uses the location (LO) to get the area emergency treatment(ESZ) in ERDB and determine the ESGW R-URI that routes to the PSAP in this area. This information will be send to Call Server (ESGWRI). Another possibility is the VPC send data concerning the emergency area (ERT), in this case the Call Server resolves the URI on the basis of these received data.
  6. The VPC allocates a Key (ESQK) linked with the caller location e other call information. This association will be useful to inform the PSAP attendant (via ALI-PSAP) the location and identity of the caller.
  7. The Call Server with the R-URI received from the VPC (ESGWRI) or with the R-URI solved with the data received from the emergency area (ERT) forwards the INVITE to the appropriate ESGW. The Call Server includes in this INVITE the ESQK and the callback number.
  8. The ESGW choose an output path for the PSTN based in ESGWRI information. In PSTN, the SS#7 signaling will include ESQK in ANI field.
  9. The SR using ESGWRI and ESQK forwards the call to the appropriate PSAP.
  10. The PSAP attendent queries the ALI using ESQK to get the caller location
  11. The ALI sends a ESPOSREQ signal for the VPC, the VPC through the key ESQK get the location and call information stored.
  12. To terminate the call the Call Server receives a BYE from caller or ESGW gateway.The Call Server must inform the VPC the end of this call to release the key and information concerning this call.

The signal flow exchanged in the first scenario is shown in the figure below:

Scenario II

Call Server of caller VSP routes the emergency call for a Routing Proxy from a third party SIP provider, which makes treatment and henceforth takes over the call.

In this scenario the interfaces: v0, v3, v7, v8, as well as the PSTN interfaces, are identical to those of scenario I, therefore will not be described here. The following figure shows the operating sketch for this scenario:

The differential steps for this scenario are listed below:

  1. The endpoint starts an emergency call by sending an INVITE to the VSP Call Server with a R-URI: 911@VSPdomain, location information is included in this package: in Geolocation header(by reference) or in body with the application/pidf content, and callback number in From header.
  2. Call Server forwards the emergency call for a Routing Proxy from a third party SIP provider keeping the same location information of INVITE received.
  3. The Routing Proxy treat the call in same way that Call Server in scenario I. It requests the routing information to the call by sending to VPC the following data: caller number, subscriber identity, location information (LO or LK).
  4. Analogously to the scenario I, the VPC uses the location (LO) to get routing information for this call (esgwri/ert, esqk, lro) from ERBD, and responds to Routing Proxy the found information.
  5. The Routing Proxy with the R-URI received from the VPC (ESGWRI) or with the R-URI solved with the data received from the emergency area (ERT), forwards the INVITE to the appropriate ESGW. The Routing Proxy includes esqk and callback number in this INVITE.
  6. To terminate the call the Routing Proxy receives a BYE from caller or ESGW gateway. The Routing Proxy must inform the VPC the end of this call to release the key and information concerning this call.

The signal flow exchanged in the second scenario is shown in the figure below:

Scenario III

Call Server of caller VSP requests from a Redirect Server the other provider routing information to emergency call, but in this case the Call Server that forwards and takes over the call. This third provider may be a provider specialized in the treatment of emergency call.

In this scenario the interfaces: v0, v3, v7, v8, as well as the PSTN interfaces, are identical to those of scenario I therefore will not be described here. The following figure shows the scenario:

The differential steps for this scenario are listed below:

  1. The endpoint starts an emergency call by sending an INVITE to the VSP Call Server with a R-URI: 911@VSPdomain, location information is included in this package: in Geolocation header(by reference) or in body with the @application/pidf@ content, and callback number in From header.
  2. Call Server forwards the emergency call for a Redirect Server from a third party SIP provider keeping the same location information of INVITE received.
  3. The Redirect Server requests the routing information to the call by sending to VPC the following data: caller number, subscriber identity, location information (LO or LK).
  4. Analogously to the scenario I, the VPC uses the location (LO) to get routing information for this call (esgwri/ert, esqk, lro) from ERBD, and responds to Redirect Server the found information.
  5. The Redirect carry the routing information received in the header Contact of 300 (Multiple Choice) response and sends to Call Server.
  6. The Redirect also sends a SUBSCRIBE request to the Call Server. This subscription request aims to monitor the status of the emergency call. The Call Server replies with a NOTIFY accepting the claim for subscription.
  7. Call Server will use the routing information received in the header Contact to forward the INVITE(directly using the ESGWRI or resolving the URI through of the emergency area information(ERT) depending on what have received) to the appropriate ESGW. The Call Server includes the esqk and callback number in this INVITE.
  8. To terminate the call the Call Server receives a BYE from caller or ESGW gateway and sends a NOTIFY to Redirect Proxy reporting the status of the call as terminated.
  9. The Redirect sends SUBSCRIBER with Expires header with zero value, to finish the subscription. The Call Server confirm the end of subscription with a NOTIFY.
  10. The Redirect Server must inform the VPC the end of this call to release the key and information concerning this call.

The signal flow exchanged in the third scenario is shown in the following picture:

5.  OpenSIPS

In this architecture OpenSIPS can act as the Call Server, as Redirect Server or as Routing Proxy depending on the role you want to assign it in each scenario.

The emergency module was developed to make OpenSIPS fulfill the functional requirements demanded by NENA. This module includes some parameters to be set in the configuration script, and we created two new functions: emergency_call dealing with forwarding the request to emergency call and failure which treats any failure of transmission of the forwarded request.

The next section addresses the tasks that these functions perform and explain the parameters. Initially we are going start by the parameters that are common regardless of the OpenSIPS' role to be configured for the module emergency:

Emergency Module Tables 

              - selectiveRoutingID: The Common Language Location Indicator (CLLI) code associated with the Selective Router to which the emergency call is to be directed.
              - routingESN: The Emergency Services Number associated with a particular ESZ that represents a unique combination of Police, Fire and EMS emergency responders.
              - npa:  The Numbering Plan Area associated with the outgoing route to the Selective Router that is appropriate for caller’s location.
              - esgwri:  this field will contain the Routing Key that allows routing of the call to the Selective Router servicing the local area in which the call was made.

              - organizationName: provider company name’s. This parameter is optional field in the NENA v2 interface (call server - VPC).
              - hostId: provider hostname’s. This parameter is  mandatory if attribution is 0(source) or 2(VSP), otherwise it is optional.
              - nenaId: the NENA administered company identifier (NENA Company ID) of provider. This parameter is optional field in the NENA v2 interface (call server - VPC).
              - contact: telephone number by which the provider operator can be reached 24 hours a day, 7 days a week. This parameter is  mandatory if attribution is 0(source) or 2(VSP), otherwise it is optional.
              - certUri: provides a means of directly obtaining the VESA(Valid Emergency Services Authority) issued certificate for the provider. This parameter is optional field in the NENA v2 interface (call server - VPC).
              - nodeIp: IP address of the node that is being registered. This parameter is  mandatory.
              - attribution: It is a field of type int designating the function of the organization involved in the composition of architecture NENA being registered in this table. This parameter is  mandatory. 
The values that this field can take are: 
                        1 - the organization is a Source. Source is node directly requesting emergency call routing from the VPC;
                        2 - the organization is a VPC. VPC is the routing information provider to emengency call;
                        3 -  the organization is a VSP. VSP is the caller's voice service provider; 

              - callid: INVITE header that uniquely identifies the call at the Call Server.
              - vpc_organizationName: is VPC company name’s 
              - vpc_hostname: is VPC hostname.
              - vpc_timestamp: is the date time stamp in UTC time format indicating the time that the message was sent from the VPC node.
              - selectiveRoutingID: The Common Language Location Indicator (CLLI) code associated with the Selective Router to which the emergency call is to be directed.
              - routingESN: The Emergency Services Number associated with a particular ESZ that represents a unique combination of Police, Fire and EMS emergency responders.
              - npa: The Numbering Plan Area (NPA) associated with the outgoing route tothe Selective Router that is appropriate for caller’s location.
              - lro: last routing option.This routing option should only be used by the call server or proxy as a last resort.
              - result: code indicating the reason for success or failure to VPC determine an routing.
              - disposition: disposition of the call (e.g., ESGWRI or LRO used).

Configuration Script 

loadmodule "emergency.so" # loads the module

### mandatory parameters
# defines URL database where store relevant tables to the emergency module
modparam("emergency", "db_url", "mysql://opensips:opensipsrw@localhost/opensips")

# defines emergency codes that OpenSIPS should consider for treating emergency call
modparam("emergency", "emergency_codes", "911-Código de emergência dos EUA")
modparam("emergency", "emergency_codes", "112-Código de Emergência Europeu")

### optional parameters
# time interval in which OpenSIPS carries to memory the data in the routing table in order to optimize server performance
modparam("emergency", "timer_interval",30)

The other parameters and tasks which the functions execute depends on its role within the possible scenarios.

5.1  Call Server in the scenario I or as the Routing Server in scenario II
/*
* emergency module tables in this role:
* emergency_service_provider - need be created and inserted registers with organization information of VPC, Source and VSP nodes, latter only to scenario II (attribution 0, 1 and 2 respectively).
* emergency_routing - need be created and inserted with ERT information and  its ESGWRI matching , only in case of VPC don't do it.
* emergency_report - need be only created.
**/
### mandatory parameters to configure in this roles:
#proxy role = 0 defines the OpenSIPS as Call Server in scenario I
modparam("emergency", "proxy_role", 0)  
#proxy role = 1 defines the OpenSIPS as Routing Server for scenario II 
modparam("emergency", "proxy_role", 1)  

#VPC's IP address that OpenSIPS interfaces to get routing data.
modparam("emergency", "url_vpc", "http://192.168.0.103/fcgi-bin/fcgid.fcgi") 

###optional parameters to configure in this roles:
#contingency proxy URI to route the emergency call, if the routing mechanism made between OpenSIPS and VPC fails. 
modparam("emergency", "contingency_hostname","192.168.0.105")  

#name of the table that makes the replacement of emergency area identity received of VPC(ERT) in URI to routing the request.
modparam("emergency", "db_table_routing","emergency_routing")  

#name of the table that store metadata associated with a call
modparam("emergency", "db_table_report","emergency_report") 

#name of the table that store organization infomation used in VPC interface
modparam("emergency", "db_table_provider","emergency_service_provider")

Tasks performed by emergency_call function in this role:

  1. Verify the received request (INVITE) is concerning an emergency call.This is done by checking whether the User field in R-URI coincides with one of emergency_codes parameters defined in the configuration file, or, if it is a standardized URN for emergency call urn: service.sos proposed in RFC5031[7]. If it is not emergency, the package follows the usual treatment.
  2. If it is a emergency call request, it checks whether a packet is to be handled by this proxy. For this checks if the host field in R-URI is to own OpenSIPS, or check if Geolocation-Routing header has the value yes according to RFC6442[8]. If the OpenSIPS not have to deal with the package, the package is usually transmitted to a the destination set in R-URI,
  3. Get the location information of caller passed by value in body of the INVITE using content type application/pidf [9], or by reference through Geolocation headers[7]. Send HTTP POST to the VPC reporting the location along with VPC identity, VSP identity and SIP provider of Routing Proxy, latter only to scenario II. These information must be configured in the parameters described above in order to fulfill the requirements of this interface.
  4. The OpenSIPS waiting for a response 200 OK from VPC with necessary information to forward the INVITE, this information may come in two ways:
    1. via parameter ESGWRI (Emergency Services Gateway Route Identifier) ​​which already contains an URI for the Call Server to forward the call.
    2. or via parameter ERT (Emergency Route Touple), which contains three fields identifying the emergency area: Selective Routing Identifier, ESN (Emergency Services Number) and the NPA (Numbering Plan Area). The Call Server/ Routing Proxy translates these fields to an URI that the request should be routed. this is done by populating the table defined by db_emergency_routing containing the columns of the ERT field and a column that translates the target URI.
  5. In forwarding the INVITE the R-URI should be changed by the ESGWRI value, location information should be kept in package, and information concerning to CBN( Callback Number) and the key associated with the call in VPC (ESQK) should be added.
  6. The new URI destination should be kept within the OpenSIPS, this way all request within of dialogue with same callid and same direction can be forwarded to same destination. Route-Records must be included in package because OpenSIPS need be aware of the call termination.
  7. When the call ends the OpenSIPS should receive the BYE and clear the information stored in memory relating to this call. The OpenSIPS send another HTTP POST informing the VPC about the call termination, so the VPC also release the key and the information concerning this call from its base.
  8. The OpenSIPS should store the metadata of call in its database.

Tasks performed by failure function in this role:

If no succeed in transmitting the INVITE by routing defined in above steps, configuration file must contain the failure() command in FAILURE ROUTE. This command transmits the INVITE to a gateway that forwards the call to the conventional telephone network to a contingency number defined by LRO parameter received from VPC.

5.2  Call Server in the scenario II

/* emergency module tables in this role:
 * no table needs to be created.
**/
      ###mandatory parameters to configure in this roles:
#proxy role = 2 defines OpenSIPS as Call Server in scenario II
modparam("emergency", "proxy_role", 2) 

#defines the IP address of the Routing proxy from a third party SIP provider that will handle the emergency call.
modparam("emergency", "emergency_call_server","192.168.0.105")

Tasks performed by ##emergency_call## function in this role:

  1. Verify the received request (INVITE) is concerning an emergency call. This is done by checking whether the User field in R-URI coincides with one of emergency_codes parameters defined in the configuration file, or, if it is a standardized URN for emergency call urn: service.sos proposed in RFC5031 [7]. If it is not emergency, the package follows the usual treatment.
  2. If it is a emergency call request, it checks whether a packet is to be handled by this proxy. For this checks if the host field in R-URI is to own OpenSIPS, or check if Geolocation-Routing header has the value yes according to RFC6442[8]. If the OpenSIPS not have to deal with the package, the package is usually transmitted to a the destination set in R-URI.
  3. Only forwards the INVITE to Routing Proxy that will take this call.

The command failure has no meaning in this role.

5.3  Call Server in the scenario III
/* emergency module tables in this role:
 * emergency_service_provider – not need be created.
emergency_routing - need be created and inserted with ERT information and  its ESGWRI matching , only in case of VPC don't do it.
 * emergency_report - need be only created.
**/
      ###mandatory parameters to configure in this roles:
#proxy role = 3 defines Opensips as Call Server in scenario III
modparam("emergency", "proxy_role", 3) 

#defines the IP address of Redirect Server that will handle the emergency call.
modparam("emergency", "emergency_call_server","192.168.0.105")


      ###optional parameters to configure in this roles:
#contingency proxy URI to route the emergency call, if the routing mechanism made between OpenSIPS and VPC fails
modparam("emergency", "contingency_hostname","192.168.0.105")  

#name of the table that makes the replacement of emergency area identity received of VPC(ERT) in URI to routing the request.
modparam("emergency", "db_table_routing","emergency_routing")  

#name of the table that store metadata associated with a call
modparam("emergency", "db_table_report","emergency_report")

Tasks performed by emergency_call function in this role:

  1. Verify the received request (INVITE) is concerning an emergency call.This is done by checking whether the User field in R-URI coincides with one of emergency_codes parameters defined in the configuration file, or, if it is a standardized URN for emergency call urn: service.sos proposed in RFC5031[7]. If it is not emergency, the package follows the usual treatment.
  2. If it is a emergency call request, it checks whether a packet is to be handled by this proxy.For this checks if the host field in R-URI is to own OpenSIPS, or check if Geolocation-Routing header has the value yes according to RFC6442[8]. If the OpenSIPS not have to deal with the package, the package is usually transmitted to a the destination set in R-URI
  3. Forward the INVITE for a Redirect Server and expect to receive a 300/302 response to collect the data in the header Contact.
  4. Using the target URI of the INVITE stated in treatment of command failure() to redirect for the same destination all request within this dialog.
  5. Receive the SUBSCRIBE request of the Redirect Server to event type with "dialog" defined by RFC 4235, and create the subscription to monitor the status of this emergency call and notify the Redirect when occur the call end. The Call Server must send the Redirect one NOTIFY confirming that the SUBSCRIBE was accepted.
  6. When the call ends the OpenSIPS should receive the BYE and clear the information stored in memory relating to this call. Call Server must send a NOTIFY to Redirect reporting the end this call, then should expect to receive a SUBSCRIBE with the Expires header with zero value, indicating the close of subscription.The Call Server responds again with a NOTIFY with status terminated confirming closure of the subscription according to RFC 6665.
  7. The OpenSIPS should store the metadata of call in its database.

Tasks performed by failure function in this role:

  1. The failure command will treat the 300/302 response received from redirect, and will use the information in Contact header to forward INVITE to the correct destination. Contact header may come in two ways:
    1. via parameter ESGWRI (Emergency Services Gateway Route Identifier) ​​which already contains an URI for the Call Server to forward the call.
    2. or via parameter ERT (Emergency Route Touple), which contains three fields identifying the emergency area: Selective Routing Identifier, ESN (Emergency Services Number) and the NPA (Numbering Plan Area). The Call Server/ Routing Proxy translates these fields to an URI that the request should be routed. this is done by populating the table defined by db_emergency_routing containing the columns of the ERT field and a column that translates the target URI.
  2. In the forwarding of the INVITE, the R-URI should be changed by ESGWRI value, and location information should be kept in the package and should be added information of CBN and ESQK (Emergency Services Query Keys). And the Route-Records must be included in the message for the OpenSIPS be aware of the closure of the call.
  3. If no succeed in transmitting the INVITE by routing defined in above steps, this command transmits the INVITE to a gateway that forwards the call to the conventional telephone network to a contingency number defined by LRO parameter received from VPC.
5.4  Redirect Server in the scenario III
/* emergency module tables in this role:
 * emergency_service_provider - need be created and inserted registers with organization information of VPC, Source and VSP nodes (attribution 0, 1 and 2 respectively).
 * emergency_routing - not need be created .
 * emergency_report - need be only created.
**/
      ###mandatory parameters to configure in this roles:
#proxy role = 4 defines Opensips as Redirect Server in scenario III
modparam("emergency", "proxy_role", 4) 

#VPC's IP address that OpenSIPS interfaces to get routing data
modparam("emergency", "url_vpc", "http://192.168.0.103/fcgi-bin/fcgid.fcgi")


      ###optional parameters to configure in this roles:
#name of the table that store metadata associated with a call
modparam("emergency", "db_table_report","emergency_report")

Tasks performed by emergency_call function in this role:

  1. Verify the received request (INVITE) is concerning an emergency call. This is done by checking whether the User field in R-URI coincides with one of emergency_codes parameters defined in the configuration file, or, if it is a standardized URN for emergency call urn: service.sos proposed in RFC5031[7]. If it is not emergency, the package follows the usual treatment.
  2. If it is a emergency call request, it checks whether a packet is to be handled by this proxy. For this checks if the host field in R-URI is to own OpenSIPS, or check if Geolocation-Routing header has the value yes according to RFC6442[8]. If the OpenSIPS not have to deal with the package, the package is usually transmitted to a the destination set in R-URI.
  3. Get the location information of caller passed by value in body of the INVITE using content type application/pidf[9], or by reference through Geolocation headers [7]. Send HTTP POST to the VPC reporting the location along with VPC identity, VSP identity and SIP provider of Routing Proxy. These information must be configured in the parameters described above in order to fulfill the requirements of this interface.
  4. The OpenSIPS waiting for a response 200 OK from VPC with necessary information to forward the INVITE, this information may come in two ways:
    1. via parameter ESGWRI (Emergency Services Gateway Route Identifier) ​​which already contains an URI for the Call Server to forward the call.

or via parameter ERT (Emergency Route Touple), which contains three fields identifying the emergency area: Selective Routing Identifier, ESN (Emergency Services Number) and the NPA (Numbering Plan Area). The Call Server/ Routing Proxy translates these fields to an URI that the request should be routed. this is done by populating the table defined by db_emergency_routing containing the columns of the ERT field and a column that translates the target URI. This information must be included in Contact header in a response 300/302 to be transmitted to the Call Server, for it can routing the INVITE

  1. Redirect Server must also send a SUBSCRIBE with event type as "dialog" (RFC 4235) to establish a subscription in Call Server aiming monitor the emergency call, and expects to receive a NOTIFY confirming subscription
  2. Expects the Call Server send another NOTIFY when end the call, so the Redirect can signal the VPC to release the key and the information associated with the call in progress.
  3. Redirect again sends a SUBSCRIBE with Expires header equal to zero to finish the subscription with Call Server, and waits receiving a NOTIFY with status terminated to confirm the close (RFC 6665).

The command failure has no meaning in this role.

6.  Configuration Example

### use of emergency_call command with OpenSIPS working as Call Server
# in the scenarios I, II, III and Routing Server in scenario II
####### Routing Logic ########
route{              
            if (!mf_process_maxfwd_header("10")) {
                        sl_send_reply("483","Too Many Hops");
                        exit;
            }
 
            # emergency call - start
            xlog("CONF -----verify EMERGENCY -----------\n");
            if (emergency_call()) {
                        t_on_failure("emergency_call");
                        t_relay();
                        exit;
            } else {
                        xlog("CONF-------NOT EMERGENCY – CONTINUE WITH OTHES CALLS TREATMENTS -----------\n");             
            }
            # emergency call – end
            ...
}

### use of failure command with OpenSIPS working as Call Server in scenarios I
# and Routing Server for scenario II, this command does not make sense to
# OpenSIPS working as Call Server in scenarios II and III:
failure_route[emergency_call] { 
            xlog(" FAILURE ... \n");
            if(failure()){
                        #record_route(); use this only in role_proxy = 3
                        xlog(" RETRANSMITE  ... \n");
                        if (!t_relay()) {
                           send_reply("500","Internal Error");
                           exit;
                        };
                        t_on_failure("emergency_call");
                        exit;
            }
}

### use of emergency_call command with OpenSIPS working as Proxy Redirect in
# scenario III (in this case we do not need t_relay () command because the
# INVITE received will not be forwarded). The failure command also does not
# make sense in this paper:
####### Routing Logic ########
route{              
            if (!mf_process_maxfwd_header("10")) {
                        sl_send_reply("483","Too Many Hops");
                        exit;
            }
            # emergency call - start
            xlog("CONF -----verify EMERGENCY -----------\n");
            if (emergency_call()){
                        t_on_failure("emergency_call");
                        exit;
            }else{
                        xlog("CONF-------NOT EMERGENCY – CONTINUE WITH OTHES CALLS TREATMENTS -----------\n");                         
            }
            #emergency call – end
            ...
}

7.  References

  1. Hannes Tschofenig, Henning Schulzrinne. Internet Protocol-Based Emergency Sercices. 2013.
  2. NENA. NENA Interim VoIP Architecture for Enhanced 9-1-1 Services (i2) NENA 08-001 v2. Agosto 2013.
  3. H. Schulzrinne. Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information. Novembro 2006, RFC 4776, Internet Engineering Task Force.
  4. Polk, J., Linsner, M., Thomson, M. and Aboba, B. Dynamic Host Configuration Protocol Option for Coordinate-Based Location Configuration Information, July 2011. RFC 6225, Internet Engineering Task Force.
  5. Barnes, M. HTTP-Enabled Location Delivery (HELD), September 2010. RFC 5985, Internet Engineering Task Force.
  6. Hardie, T., Newton, A., Schulzrinne, H. and Tschofenig, H. LoST: A Location-to-Service Translation Protocol,August 2008. RFC 5222, Internet Engineering Task Force.
  7. Schulzrinne, H. A Uniform Resource Name (URN) for Emergency and Other Well-Known Services, January 2008. RFC 5031, Internet Engineering Task Force.
  8. Polk, J. and Rosen, B. Location Conveyance for the Session Initiation Protocol, December 2011. RFC 6442, Internet Engineering Task Force.
  9. Berners-Lee, T., Fielding, R. and Masinter, L. Uniform Resource Identifier (URI): Generic Syntax, January 2005. RFC 3986, Internet Engineering Task Force.
  10. Peterson, J. A Presence-Based GEOPRIV Location Object Format, December 2005. RFC 4119, Internet EngineeringTask Force.
  11. Intrado PSAP Operations Guide for Wireless 9-1-1. July 2005
  12. NENA. NENA Technical Requirements Document (TRD) for Location Information to Support IP-Based Emergency Services NENA 08-752, Issue 1, December 21, 2006
  13. B. Rosen, J. Polk. Best Current Practice for Communications Services in Support of Emergency Calling, March 2013. RFC 6881, Internet Engineering Task Force.
  14. B. Rosen, H. Schulzrinne, J. Polk, A. Newton. Framework for Emergency Calling Using Internet Multimedia, December 2011. RFC 6443, Internet Engineering Task Force.
  15. J. Cuellar, J. Morris, D. Mulligan, J. Peterson, J. Polk. Geopriv Requirements, February 2004. RFC 3693, Internet Engineering Task Force.
  16. J. Winterbottom, M. Thomson, R. Barnes,B. Rosen,R. George. Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO), January 2013. RFC 6848, Internet Engineering Task Force.
  17. R. Barnes, M. Lepinski, A. Cooper, J. Morris, H. Tschofenig, H. Schulzrinne. An Architecture for Location and Location Privacy in Internet Applications, July 2011. RFC 6280, Internet Engineering Task Force
  18. H. Tschofenig, H. Schulzrinne. GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirement, March 2010. RFC 5687, Internet Engineering Task Force
  19. M. Thomson, J. Winterbottom. Using Device-Provided Location-Related Measurements in Location Configuration Protocol, January 2014. RFC 7105, Internet Engineering Task Force
Retrieved from https://www.opensips.org/Documentation/Tutorials-Emergency-2-4
Page last modified on December 11, 2015, at 01:30 PM