Emergency Call Module
     __________________________________________________________

   Table of Contents

   1. Admin Guide

        1.1. Overview
        1.2. Dependencies

              1.2.1. OpenSIPS Modules
              1.2.2. External Libraries or Applications

        1.3. Exported Parameters

              1.3.1. db_url (string)
              1.3.2. db_table_routing (string)
              1.3.3. db_table_report (string)
              1.3.4. db_table_provider (string)
              1.3.5. proxy_role (integer)
              1.3.6. url_vpc (string)
              1.3.7. emergency_codes (string)
              1.3.8. timer_interval (interger)
              1.3.9. contingency_hostname (string)
              1.3.10. emergency_call_server (string)

        1.4. Exported Functions

              1.4.1. emergency_call()
              1.4.2. failure()

   2. Contributors

        2.1. By Commit Statistics
        2.2. By Commit Activity

   3. Documentation

        3.1. Contributors

   List of Tables

   2.1. Top contributors by DevScore^(1), authored commits^(2) and
          lines added/removed^(3)

   2.2. Most recently active contributors^(1) to this module

   List of Examples

   1.1. Setting the db_url parameter
   1.2. Setting the db_table_routing parameter
   1.3. Setting the db_table_report parameter
   1.4. Setting the db_table_provider parameter
   1.5. Setting the proxy_role parameter
   1.6. Setting the url_vpc parameter
   1.7. Setting the emergency_codes parameter
   1.8. Setting the timer_interval parameter
   1.9. Setting the contingency_hostname parameter
   1.10. Setting the emergency_call_server parameter
   1.11. emergency_call() usage
   1.12. failure() usage

Chapter 1. Admin Guide

1.1. Overview

   The emergency module provides emergency call treatment for
   OpenSIPS, following the architecture i2 specification of the
   American entity NENA. (National Emergency Number Association).
   The NENA solution routes the emergency call to a closer gateway
   (ESGW) and this forward the call to a PSAP(call center
   responsible for answering emergency calls) that serves the area
   of ​​the caller, so this must consider the handling and
   transport of caller location information in the SIP protocol.
   To attend this new need the NENA solution consists of several
   servers: to determine the location (LIS), to determine the area
   of emergency treatment depending on location (VPC), validate
   location stored (VDB), among others. Along with these elements
   have the SIP Proxy that interface with these servers to route
   the call. The OpenSIPS can do the functions of these SIP Proxy
   through this emergency module, may perform the function of a
   Call Server, Redirect Server and Routing Proxy, depending on
   the proposed scenario:
     * scenario I: The VSP(Voip Serve Provide) retains control
       over the processing of emergency calls. The VSP’s Call
       Server implements the v2 interface that queries the VPC for
       routing information, with this information selects the
       proper ESGW, if normal routing fails routes calls via the
       PSTN using the contingency number(LRO).
     * scenario II: The VSP transfers all emergency calls to
       Routing Proxy provider using the v6 SIP interface. Once
       done transfer the VSP no longer participates in the call.
       The Routing Proxy provider implements the v2 interface,
       queries the VPC for for routing information, and forwards
       the call.
     * scenario III: The VSP requests routing information for the
       Redirect Server operator, but remains part of the call. The
       Redirect Server obtains the routing information from the
       VPC. It returns the call to the VSP’s Call Server with
       routing information in the SIP Contact Header. The Call
       Server selects the proper ESGW based on this information.

   The emergency module allows the OpenSIPS play the role of a
   Call Server, a Proxy or Redirect Server Routing within the
   scenarios presented depending on how it is configured.

   1.2. Scenario I: The VSP that originating the call is the same
   as handle the call and sends the routing information request to
   the VPC. The emergency module through emergency_call() command
   will check if the INVITE received is an emergency call. In this
   case, the OpenSIPS will get caller location information from
   specific headers and body in the INVITE. With this information
   along configuration parameters defined for this module, the
   opensips implements the v2 interface that queries the VPC for
   routing information (i.e., ESQK, LRO, and either the ERT or
   ESGWRI), selects the proper ESGW based on the ESGWRI. When the
   call ends the OpenSIPS receives BYE request, it warns the VPC
   for clean your data that is based on the call. The OpenSIPS
   through failure() command will try to route the calls via the
   PSTN using a national contingency number(LRO) if normal routing
   fails.

   1.3.Scenario II: The VSP transfers the call to a Routing Server
   provider The emergency module through emergency_call() command
   will check if the INVITE received is an emergency call. In this
   case, it will forward the call to a Routing Proxy that will
   interface with the VPC and route the call. The OpenSIPS will
   leave the call, and all the request of this dialog received by
   the opensips will be forwarded to the Routing Server.

   1.4.Scenario III: The VSP requests routing information for the
   Redirect Server The emergency module through emergency_call()
   command will check if the INVITE received is an emergency call.
   In this case, it requests routing information to Redirect
   Server. The Redirect has interface with the VPC and return to
   VSP's Call Server response whith routing informations on
   Contact header. The Call Server uses this information to treat
   the call. When the emergency call ends, it must notify the
   Redirect Server that inform to VPC to release the resources.
   To use this module should informs the mandatory parameters in
   script and make the correct filling out of the emergency module
   tables, in accordance with the role chosen within the described
   scenarios. For more details check the "Emergency calls using
   OpenSIPS".

1.2. Dependencies

1.2.1. OpenSIPS Modules

   The following modules must be loaded before this module:
     * Dialog - Dialoge module..
     * TM - Transaction module..
     * RR - Record-Route module..

1.2.2. External Libraries or Applications

   The following libraries or applications must be installed
   before running OpenSIPS with this module loaded:
     * libcurl.

1.3. Exported Parameters

1.3.1. db_url (string)

   The database url must be specified.

   Default value is “NULL”.

   Example 1.1. Setting the db_url parameter
...
modparam("emergency", "db_url", "mysql://opensips:opensipsrw@localhost/o
pensips”)
...

1.3.2. db_table_routing (string)

   The name of the db table storing routing information to
   emergency calls.

   Default value is “emergency_routing”.

   Example 1.2. Setting the db_table_routing parameter
...
modparam("emergency", "db_table_routing", "emergency_routing")
...

1.3.3. db_table_report (string)

   The name of the db table that stores the emergency call report.

   Default value is “emergency_report”.

   Example 1.3. Setting the db_table_report parameter
...
modparam("emergency", "db_table_report", "emergency_report")
...

1.3.4. db_table_provider (string)

   The name of the db table that stores the nodes information of
   organization involved in emergency calls.

   Default value is “emergency_service_provider”.

   Example 1.4. Setting the db_table_provider parameter
...
modparam("emergency", "db_table_provider", "emergency_service_provider")
...

1.3.5. proxy_role (integer)

   This parameter define what role the opensips will take to treat
   emergency call:

   0 – The opensips is the Call Server in scenario I. In this role
   the opensips implements the V2 interface, directly queries the
   VPC for ESGWRI/ESQK, selects the proper ESGW given the ESGWRI
   and routes calls Via the PSTN using the LRO if routing fails.

   1 – The opensips is the Call Server in scenario II that sends
   the INVITE on emergency call to a Routing Proxy provider. The
   Routing Proxy provider implements the V2 interface.

   2 - The opensips is the Routing Proxy in scenario II. In this
   role the opensips implements the V2 interface, directly queries
   the VPC for ESGWRI/ESQK, selects the proper ESGW given the
   ESGWRI and routes calls Via the PSTN using the LRO if routing
   fails.

   3 - The opensips is the Redirect Proxy in scenario III that
   receives the INVITE on emergency call from Call Server. The
   Redirect Server obtains the ESGWRI/ESQK from the VPC and sends
   in the SIP 3xx response to the Call Server.

   4 - The opensips is the Call Server in scenario III that sends
   the INVITE on emergency call to a Redirect Server. The Redirect
   Server obtains the ESGWRI/ESQK from the VPC. It returns the
   call to the opensips with the ESGWRI/ESQK in the header contact
   in the SIP response. The opensips selects the proper ESGW based
   on the ESGWRI.

   Default value is “0”.

   Example 1.5. Setting the proxy_role parameter
...
modparam("emergency", "proxy_role", 0))
...

1.3.6. url_vpc (string)

   The VPC url that opensips request the routing information to
   emergency call. This VPC url has IP:Port format

   Default value is “empty string”.

   Example 1.6. Setting the url_vpc parameter
...
modparam("emergency", "url_vpc", “192.168.0.103:5060”)
...

1.3.7. emergency_codes (string)

   Local emergency number. Opensips uses this number to recognize
   a emergency call beyond the username default defined by
   RFC-5031 (urn:service.sos.). Along with the number should be
   given a brief description about this code. The format is
   code_number-description. It can register multiple emergency
   numbers.

   Default value is “NULLg”.

   Example 1.7. Setting the emergency_codes parameter
...
modparam("emergency", "emergency_codes", “911-us emegency code”)
...

1.3.8. timer_interval (interger)

   Sets the time interval polling to make the copy in memory of
   the db_table_routing.

   Default value is “10”.

   Example 1.8. Setting the timer_interval parameter
...
modparam("emergency","timer_interval",20)
...

1.3.9. contingency_hostname (string)

   The contingency_hostname is the url of the server que will
   route the call to the PSTN using the number of contingency.

   Default value is “NULL”.

   Example 1.9. Setting the contingency_hostname parameter
...
modparam("emergency","contingency_hostname",“176.34,29.102:5060”)
...

1.3.10. emergency_call_server (string)

   The emergency_call_server is the url of the Routing
   Proxy/Redirect Server that will handle the emergency call in
   cenario II. Its is mandatory if Opensips act as Call Server in
   scenario II (proxy_role = 1 and flag_third_enterprise = 0) or
   Call Server in scenario III (proxy_role = 2).

   Default value is “NULL”.

   Example 1.10. Setting the emergency_call_server parameter
...
modparam("emergency","emergency_call_server",“124.78.29.123:5060”)
...

1.4. Exported Functions

1.4.1.  emergency_call()

   Checks whether the incoming call is an emergency call, case it
   is treats, and routes the call to the destination determined by
   VPC. The function returns true if is a emergency call and the
   treat was Ok.

   This function can be used from the REQUEST routes.

   Example 1.11. emergency_call() usage
...
# Example of treat of emergency call

    if (emergency_call()){

        xlog("emergency call\n");
        t_on_failure("emergency_call");
        t_relay();
        exit;

        }
...

1.4.2.  failure()

   This function is used when trying to route the emergency call
   to the destination specified by the VPC and doesn't work, then
   uses this function to make one last attempt for a contingency
   number. The function returns true if the contingency treat was
   OK.

   This function can be used from the FAILURE routes.

   Example 1.12. failure() usage
...
# Example od treat of contingency in emergency call

    if (failure()) {
        if (!t_relay()) {
           send_reply(500,"Internal Error");
        };
        exit;
    }
...

Chapter 2. Contributors

2.1. By Commit Statistics

   Table 2.1. Top contributors by DevScore^(1), authored
   commits^(2) and lines added/removed^(3)
     Name DevScore Commits Lines ++ Lines --
   1. Evandro Villaron (@evillaron) 152 9 10947 3011
   2. Robison Tesini (@rtesini) 62 1 3116 2038
   3. Razvan Crainea (@razvancrainea) 26 17 331 338
   4. Liviu Chircu (@liviuchircu) 19 13 134 188
   5. Bogdan-Andrei Iancu (@bogdan-iancu) 11 9 52 52
   6. Alexandra Titoc 10 8 62 19
   7. Maksym Sobolyev (@sobomax) 6 4 18 17
   8. Peter Lemenkov (@lemenkov) 5 3 38 17
   9. Walter Doekes (@wdoekes) 4 2 4 4
   10. Zero King (@l2dy) 4 2 2 1

   All remaining contributors: Ionut Ionita (@ionutrazvanionita),
   Julián Moreno Patiño, Vlad Patrascu (@rvlad-patrascu).

   (1) DevScore = author_commits + author_lines_added /
   (project_lines_added / project_commits) + author_lines_deleted
   / (project_lines_deleted / project_commits)

   (2) including any documentation-related commits, excluding
   merge commits. Regarding imported patches/code, we do our best
   to count the work on behalf of the proper owner, as per the
   "fix_authors" and "mod_renames" arrays in
   opensips/doc/build-contrib.sh. If you identify any
   patches/commits which do not get properly attributed to you,
   please submit a pull request which extends "fix_authors" and/or
   "mod_renames".

   (3) ignoring whitespace edits, renamed files and auto-generated
   files

2.2. By Commit Activity

   Table 2.2. Most recently active contributors^(1) to this module
                      Name                   Commit Activity
   1.  Razvan Crainea (@razvancrainea)     Jul 2015 - Sep 2024
   2.  Alexandra Titoc                     Sep 2024 - Sep 2024
   3.  Maksym Sobolyev (@sobomax)          Jan 2021 - Nov 2023
   4.  Liviu Chircu (@liviuchircu)         Mar 2015 - May 2023
   5.  Walter Doekes (@wdoekes)            Apr 2021 - Apr 2021
   6.  Zero King (@l2dy)                   Mar 2020 - Aug 2020
   7.  Bogdan-Andrei Iancu (@bogdan-iancu) Mar 2015 - Mar 2020
   8.  Peter Lemenkov (@lemenkov)          Jun 2018 - Feb 2020
   9.  Vlad Patrascu (@rvlad-patrascu)     May 2017 - May 2017
   10. Julián Moreno Patiño                Feb 2016 - Feb 2016

   All remaining contributors: Evandro Villaron (@evillaron),
   Ionut Ionita (@ionutrazvanionita), Robison Tesini (@rtesini).

   (1) including any documentation-related commits, excluding
   merge commits

Chapter 3. Documentation

3.1. Contributors

   Last edited by: Liviu Chircu (@liviuchircu), Peter Lemenkov
   (@lemenkov), Julián Moreno Patiño, Evandro Villaron
   (@evillaron).

   Documentation Copyrights:

   Copyright © 2014 Villaron/Tesini
