Table of Contents
db_url (string)db_table_routing (string)db_table_report (string)db_table_provider (string)proxy_role (integer)url_vpc (string)emergency_codes (string)timer_interval (interger)contingency_hostname (string)emergency_call_server (string)List of Tables
List of Examples
db_url parameterdb_table_routing parameterdb_table_report parameterdb_table_provider parameterproxy_role parameterurl_vpc parameteremergency_codes parametertimer_interval parametercontingency_hostname parameteremergency_call_server parameteremergency_call() usagefailure() usageThe 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".The following modules must be loaded before this module:
Dialog - Dialoge module..
TM - Transaction module..
RR - Record-Route module..
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/opensips”)
...
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")
...
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")
...
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")
...
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”.
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”)
...
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”)
...
Sets the time interval polling to make the copy in memory of the db_table_routing.
Default value is “10”.
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”)
...
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”)
...
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;
}
...
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;
}
...
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) | 149 | 9 | 10947 | 3011 |
| 2. | Robison Tesini (@rtesini) | 63 | 1 | 3116 | 2038 |
| 3. | Razvan Crainea (@razvancrainea) | 23 | 14 | 314 | 321 |
| 4. | Liviu Chircu (@liviuchircu) | 15 | 10 | 122 | 174 |
| 5. | Bogdan-Andrei Iancu (@bogdan-iancu) | 10 | 8 | 47 | 50 |
| 6. | Peter Lemenkov (@lemenkov) | 4 | 2 | 37 | 16 |
| 7. | Ionut Ionita (@ionutrazvanionita) | 3 | 1 | 7 | 13 |
| 8. | Julián Moreno Patiño | 3 | 1 | 1 | 1 |
| 9. | Vlad Patrascu (@rvlad-patrascu) | 2 | 1 | 1 | 0 |
| 10. | Zero King (@l2dy) | 2 | 1 | 1 | 0 |
(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
Table 2.2. Most recently active contributors(1) to this module
| Name | Commit Activity | |
|---|---|---|
| 1. | Liviu Chircu (@liviuchircu) | Mar 2015 - Oct 2020 |
| 2. | Zero King (@l2dy) | Aug 2020 - Aug 2020 |
| 3. | Bogdan-Andrei Iancu (@bogdan-iancu) | Mar 2015 - Jun 2020 |
| 4. | Peter Lemenkov (@lemenkov) | Sep 2018 - Feb 2020 |
| 5. | Razvan Crainea (@razvancrainea) | Jul 2015 - Sep 2019 |
| 6. | Vlad Patrascu (@rvlad-patrascu) | May 2017 - May 2017 |
| 7. | Julián Moreno Patiño | Feb 2016 - Feb 2016 |
| 8. | Evandro Villaron (@evillaron) | Feb 2015 - Sep 2015 |
| 9. | Ionut Ionita (@ionutrazvanionita) | Mar 2015 - Mar 2015 |
| 10. | Robison Tesini (@rtesini) | Feb 2015 - Feb 2015 |
(1) including any documentation-related commits, excluding merge commits
Last edited by: Bogdan-Andrei Iancu (@bogdan-iancu), Liviu Chircu (@liviuchircu), Julián Moreno Patiño, Evandro Villaron (@evillaron).
doc copyrights:
Copyright © 2014 Villaron/Tesini