fix structure (#141)

* fixed structure * add github links
yeti-switch · Sep 6, 2024 · 3b54e5b · 3b54e5b
1 parent 5b438c8
commit 3b54e5b
Show file tree

Hide file tree

Showing 14 changed files with 127 additions and 140 deletions.
diff --git a/en/best-practices/best-practices.rst b/en/best-practices/best-practices.rst
diff --git a/en/headers-filtering.rst → en/best-practices/headers-transit.rst b/en/headers-filtering.rst → en/best-practices/headers-transit.rst
@@ -1,13 +1,16 @@
 
 .. :maxdepth: 2
 
-=================
-Headers filtering
-=================
+===============
+Headers transit
+===============
 
 .. _headers_fitering:
 
-Filtering headers allows to configure the transfer of SIP headers from one Leg of the call to another. After  the routing, YETI performs filtering twice: for the origination :ref:`Gateway <gateways>` and for the termination :ref:`Gateway <gateways>`.
+By default Yeti are not relaying any headers from one call leg to another. Headers transit mechanism allows to configure such relaying.
+
+
+After the routing, YETI performs filtering twice: for the origination :ref:`Gateway <gateways>` and for the termination :ref:`Gateway <gateways>`.
 Gateway's parameter **Transit headers from origination** describes the transfer of headers from LegA to LegB, the parameter **Transit headers from termination** - from LegB to LegA.
 
 For example, an incoming call arrives via the :ref:`Gateway <gateways>` **orig_gw** and terminates via the :ref:`Gateway <gateways>` **term_gw** with the corresponding settings.

diff --git a/en/best-practices/numbers-translations.rst b/en/best-practices/numbers-translations.rst
@@ -0,0 +1,93 @@
+
+.. _posix_regular_expressions2:
+
+.. |br| raw:: html
+
+   <br />
+
+====================
+Numbers translations
+====================
+
+Yeti has flexible configuration of numbers modifications - it allows to change source and destination numbers on different call processing stages:
+
+#. Before routing, immediately after call authorization at :ref:`Customers Auth <customers_auth_number_translation>`.
+#. Before routing, during :ref:`Numberlist <numberlists_rewrite_rules>` processing.
+#. After routing in :ref:`Dialpeer <dialpeer_number_translation_settings>`.
+#. After routing at termination :ref:`Gateway <gateways_number_translation>`.
+
+In most cases numbers translations implemented using `POSIX Regular Expressions <https://www.postgresql.org/docs/current/functions-matching.html#FUNCTIONS-POSIX-REGEXP>`_. This section describes general principles and examples of using POSIX Regular Expressions in Yeti. 
+
+Yeti uses Postgresql `REGEXP_REPLACE(phonenumber, rewrite_rule, rewrite_result) <https://www.postgresql.org/docs/current/functions-matching.html>`_ function with following arguments:
+
+phonenumber
+    It is a phone number (source or destination) that replacement should be taken place.
+
+rewrite_rule
+    It is a POSIX regular expression for matching substrings that should be replaced.
+
+rewrite_result
+    It is a string that to replace the substrings which match the *rewrite_rule*.
+
+
+The REGEXP_REPLACE() function returns a new phonenumber with the elements, which match a regular expression pattern, replaced by a new substring.
+
+
+Examples
+========
+
+How to add prefix 888 to number
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+    **rewrite_rule** = ^(.*)$
+    |br|
+    **rewrite_result** = 888\\1
+
+    where ^ - matches at the beginning of the phonenumber, $ - matches at the end of the phonenumber, (.*) - regular expression matches a sequence of 0 or more characters, 888 - prefix to add, \\1 - first marked subexpression matched (in our case - it is phone number (source or destination) that replacement should be taken place). Some examples of adding digits to the beginning of the phonenumber with using different arguments are provided below:
+
+       a) **original phone number** = 7335255 ;  **rewrite_rule** = ^(.*)$ ; **rewrite_result** = 0\\1 ; **resulting phone number**  = 07335255
+       b) **original phone number** = 2296132 ;  **rewrite_rule** = ^(.*)$ ; **rewrite_result** = 066\\1 ; **resulting phone number**  = 0662296132
+       c) **original phone number** = 7050460 ;  **rewrite_rule** = ^(.*)$ ; **rewrite_result** = 38048\\1 ; **resulting phone number**  = 380487050460
+
+
+How to remove prefix 999# from number
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+    **rewrite_rule** = ^999#(.*)$
+    |br|
+    **rewrite_result** = \\1
+
+
+How to add suffix 1235 to number
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+    **rewrite_rule** = ^(.*)$
+    |br|
+    **rewrite_result** = \\11235
+
+
+How to replace prefix 123# with prefix 321#
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+    **rewrite_rule** = ^123#(.*)$
+    |br|
+    **rewrite_result** = 321#\\1
+
+
+How to add 8 random digits to the end of phonenumber
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+    to generate random digits **r(N)** function may be used:
+
+    **rewrite_rule** = ^(.*)$
+    |br|
+    **rewrite_result** = \\1r(8)
+
+How to replace 4 last digits to random values
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+    **rewrite_rule** = ^(.*)(\\d{4})$
+    |br|
+    **rewrite_result** = \\1r(4)
+
+
diff --git a/en/best-practices/using-routing-tags.rst b/en/best-practices/using-routing-tags.rst
@@ -1,8 +1,8 @@
 .. :orphan:
 
-=================================================
-Using Routing tags for the routing prioritization
-=================================================
+==================
+Using Routing tags
+==================
 The Yeti Switch has rich abilities for routing traffic. And one of them is tags.
 
 Let's imagine that you need to route some calls relying on their A or B numbers (or even both) - that's not a problem.
@@ -28,4 +28,4 @@ Now, we may attach our newly created tag to a dialpeer
 .. image:: images/routing_tags_decision.png
 
 So, if any particular call already has a tag than Yeti is going to choose dialpeers having such a tag, than all others dialpeers.
-If a call don't have any tags than a routing decision will be based on all dialpeers.
+If a call don't have any tags than a routing decision will be based on all dialpeers.
diff --git a/en/conf.py b/en/conf.py
@@ -113,8 +113,8 @@
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
 # documentation.
-# html_theme_options = {
-# }
+#html_theme_options = {
+#}
 
 # Add any paths that contain custom themes here, relative to this directory.
 #html_theme_path = ["../themes"]
@@ -293,4 +293,9 @@
     "languages": [
         ("English", "../en"),
     ],
+    "display_github": True,
+    "github_user": 'yeti-switch',
+    "github_repo": 'doc',
+    "github_version": 'master',
+    "conf_py_path": '/en/'
 }
diff --git a/en/index.rst b/en/index.rst
@@ -31,9 +31,10 @@ Welcome to Yeti's documentation!
 
    quick-start/quick_start.rst
    disconnect-codes
-   headers-filtering
-   best-practices/best-practices.rst
+   best-practices/headers-transit.rst
+   best-practices/numbers-translations.rst
    best-practices/teams-direct-routing.rst
+   best-practices/using-routing-tags.rst
 
 .. toctree::
    :maxdepth: 2

diff --git a/en/quick-start/quick_start.rst b/en/quick-start/quick_start.rst
@@ -1,7 +1,9 @@
 
-================================
-Guideline on Quick start of Yeti
-================================
+=========================
+Routing quick start guide
+=========================
+
+This document explains how to configure Yeti to route your fist test call.
 
 Yeti is user-friendly application and it very easy for configuration. You can see this by looking at the diagram of dependencies between objects :)
 

diff --git a/en/web-interface/equipment/gateways.rst b/en/web-interface/equipment/gateways.rst
@@ -275,7 +275,8 @@ Signaling (Termination) **Gateway**'s attributes:
     Send lnp information
         If this checkbox is enabled (in case of using Gateway as Terminator of calls) Yeti will include Local number portability information (LNP) to the outgoing INVITE-request (by adding npdi and rn parameters to the R-URI) only in case of availability of this LNP information (it means if LNP information was successfully received from :ref:`LNP Database <lnp_databases>`). Rules of receiving LNP information from LNP Database are regulated in the :ref:`Routing plan LNP rules <routing_plan_lnp_rules>`.
 
-
+    .. _gateways_number_translation:
+
 Translations **Gateway**'s attributes:
 ``````````````````````````````````````
     Diversion policy

diff --git a/en/web-interface/general.rst b/en/web-interface/general.rst
@@ -5,7 +5,7 @@ General Information
 .. _general_information:
 
 
- YETI Web interface allows you to manage all possible entities in the system including CDRs, reporting, billing, routing, sytem configuration and others. It was developed using the most poweful and flexible web frameworks such as `Ruby on Rails <https://rubyonrails.org/>`_ and `Active Admin <https://activeadmin.info/>`_.
+ YETI Web interface allows you to manage all possible entities in the system including CDRs, reporting, billing, routing, sytem configuration and others. It was developed using the most powerful and flexible web frameworks such as `Ruby on Rails <https://rubyonrails.org/>`_ and `Active Admin <https://activeadmin.info/>`_.
 
  General structure of the YETI Web interface includes tree main sections:
 
@@ -26,6 +26,8 @@ Header & Menu line
 
  .. figure:: images/header.png
         :alt: YETI Web interface - header
+
+**Logout** button is used for exit from Yeti Web Interface.
 
 Working Area
 ============

diff --git a/en/web-interface/index.rst b/en/web-interface/index.rst
@@ -30,6 +30,4 @@ Admin WEB interface and  routing logic
    logs
    system
    yeti-ui-userprofile
-   yeti-ui-logout
-   yeti-ui-regexp_replace
 
diff --git a/...outing/yeti-ui-routing-customer_auths.rst → en/web-interface/routing/customers-auths.rst b/...outing/yeti-ui-routing-customer_auths.rst → en/web-interface/routing/customers-auths.rst
@@ -278,7 +278,7 @@ Match condition **Customers Auth**'s options
     X Yeti Auth
         It's possible to define the custom SIP-header **X-Yeti-Auth** or array of headers (separated by comma(,)) for the customer's calls and specify its value in YETI. In case they match, YETI passes such calls with using this Customer Auth entity for authentication.
 
-    .. _number_translation_settings:
+    .. _customers_auth_number_translation:
 
 Number translation **Customers Auth**'s options
 ```````````````````````````````````````````````

diff --git a/en/web-interface/routing/index.rst b/en/web-interface/routing/index.rst
@@ -13,7 +13,7 @@ On the first step of general routing algorithm :ref:`authentication <customer_au
 
 On the second step of algorithm Yeti will check Customer's balance if :ref:`Check account balance <customer_check_account_balance>` flag of selected :ref:`Customer Auth <customer_auth>` record is enabled. If current balance is less than :ref:`Min balance <account_min_balance>` call will dropped with **Disconnect code 8000** (No enough customer balance).
 
-On the third step of general routing algorithm Yeti makes pre-Routing numbers translations. Yeti rewrites (if necessary) Name field in the Source-number, Source-number and Destination-number for incoming call (by :ref:`using POSIX Regular Expressions <posix_regular_expressions2>`) with using :ref:`Number translation settings <number_translation_settings>` of  :ref:`Customer Auth <customer_auth>` record that was selected. On this step Yeti also rewrites (if necessary) Source and Destination numbers which will be send to Radius-server if it's required (by :ref:`using POSIX Regular Expressions <posix_regular_expressions2>`) with using :ref:`Radius options <radius_options>` of  :ref:`Customer Auth <customer_auth>` record that was selected.
+On the third step of general routing algorithm Yeti makes pre-Routing numbers translations. Yeti rewrites (if necessary) Name field in the Source-number, Source-number and Destination-number for incoming call (by :ref:`using POSIX Regular Expressions <posix_regular_expressions2>`) with using :ref:`Number translation settings <customers_auth_number_translation>` of  :ref:`Customer Auth <customer_auth>` record that was selected. On this step Yeti also rewrites (if necessary) Source and Destination numbers which will be send to Radius-server if it's required (by :ref:`using POSIX Regular Expressions <posix_regular_expressions2>`) with using :ref:`Radius options <radius_options>` of  :ref:`Customer Auth <customer_auth>` record that was selected.
 
 On the fourth step of general routing algorithm Yeti makes processing of destination :ref:`Numberlist <numberlists>` if this :ref:`Numberlist <numberlists>` was setted up in the :ref:`Customer Auth <customer_auth>` record. Depending on chosen :ref:`mode <numberlists_mode>` Yeti is going via all related :ref:`Numberlist items <numberlist_items>` and makes some :ref:`actions <numberlists_action>`. As a result of this step Yeti could drop the call with **Disconnect code 8001** (Destination blacklisted) or just rewrite (if necessary) Source and Destination numbers (by :ref:`using POSIX Regular Expressions <posix_regular_expressions2>`) with using :ref:`rewrite rules <numberlist_items_rewrite_rules>` of  :ref:`Numberlist items <numberlist_items>` record or :ref:`rewrite rules <numberlists_rewrite_rules>` relevant :ref:`Numberlist <numberlists>` record.
 
@@ -138,7 +138,7 @@ YETI WEB interface - Routing menu description.
 .. toctree::
    :maxdepth: 1
 
-   yeti-ui-routing-customer_auths
+   customers-auths
    yeti-ui-routing-rateplans
    yeti-ui-routing-destinations
    yeti-ui-routing-routing_groups

diff --git a/en/web-interface/yeti-ui-logout.rst b/en/web-interface/yeti-ui-logout.rst
diff --git a/en/web-interface/yeti-ui-regexp_replace.rst b/en/web-interface/yeti-ui-regexp_replace.rst