yeti-switch · dmitry-sinina · Jan 11, 2025 · Jan 11, 2025 · Jan 11, 2025
diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml
@@ -11,11 +11,14 @@ jobs:
     steps:
       - uses: actions/checkout@v2
       - name: install sphinx
-        run: pip install sphinx sphinx_rtd_theme sphinxcontrib-mermaid sphinxcontrib.googleanalytics sphinxcontrib-video
+        run: pip install sphinx sphinx_rtd_theme sphinxcontrib-mermaid sphinxcontrib.googleanalytics sphinxcontrib-video sphinxcontrib.spelling
 
       - name: install graphviz
         run: sudo apt install graphviz
 
+      - name: Run spellcheck
+        run: make spellcheck
+
       - name: Run linkcheck
         run: make linkcheck
 

diff --git a/Makefile b/Makefile
@@ -11,6 +11,9 @@ $(langs):
 linkcheck:
 	make -C $(langs) linkcheck
 
+spellcheck:
+	make -C $(langs) spelling
+
 clean: $(langs:=-clean)
 
 dep:

diff --git a/en/Makefile b/en/Makefile
@@ -171,6 +171,11 @@ linkcheck:
 	@echo "Link check complete; look for any errors in the above output " \
 	      "or in $(BUILDDIR)/linkcheck/output.txt."
 
+spelling:
+	$(SPHINXBUILD) -b spelling $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
+	@echo
+	@echo "Spell check complete; look for any errors in the above output"
+
 doctest:
 	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
 	@echo "Testing of doctests in the sources finished, look at the " \

diff --git a/en/best-practices/numbers-translations.rst b/en/best-practices/numbers-translations.rst
@@ -18,19 +18,19 @@ Yeti has flexible configuration of numbers modifications - it allows to change s
 
 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:
+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.
+    It is a POSIX regular expression for matching sub-strings that should be replaced.
 
 rewrite_result
-    It is a string that to replace the substrings which match the *rewrite_rule*.
+    It is a string that to replace the sub-strings 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.
+The REGEXP_REPLACE() function returns a new phonenumber with the elements, which match a regular expression pattern, replaced by a new sub-string.
 
 
 Examples
@@ -43,7 +43,7 @@ How to add prefix 888 to number
     |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:
+    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 sub-expression 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

diff --git a/en/best-practices/teams-direct-routing.rst b/en/best-practices/teams-direct-routing.rst
@@ -21,7 +21,7 @@ This part out of scope of this document. You have to complete next steps yoursel
 
     * Domain name for SBC address required. Domain name **A record** should point to Yeti load balancer IP address. **SRV** records not supported by MS Teams.
 
-    * Valid TLS certificate should be installed on Yeti load balancer. If you planning to using multitenacy on MS Teams side(multiple MS Teams accounts connected to same Yeti-Switch system) you have to use wildcard certificate. See https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan#public-trusted-certificate-for-the-sbc for details.
+    * Valid TLS certificate should be installed on Yeti load balancer. If you planning to using multi-tenancy on MS Teams side(multiple MS Teams accounts connected to same Yeti-Switch system) you have to use wildcard certificate. See https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan#public-trusted-certificate-for-the-sbc for details.
 
 
 #. Validate SBC domain name on Teams side using DNS TXT record according to MS Teams documentation.
@@ -73,7 +73,7 @@ Orig Append Headers Reply
     Should contain **Allow: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS**. Redefining **Allow** header there affects transfer logic on MS Teams side when call originated by MS Teams. Without this settings MS Teams will send **REFER** requests to Yeti-Switch to handle call transfer and it will fail because Yeti-Switch is not processing such requests in this scenario.
 
 Term Append Headers Req
-    Should contain **Allow: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS**. Redefining **Allow** header there affects transfer logic on teams side when call originated by Yeti to MS Teams. In case of multitenant configuration **term append headers req** should also contain **X-RR-Domain: subdomain.teams.example.com**.
+    Should contain **Allow: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS**. Redefining **Allow** header there affects transfer logic on teams side when call originated by Yeti to MS Teams. In case of multi-tenant configuration **term append headers req** should also contain **X-RR-Domain: subdomain.teams.example.com**.
 
 Term Use Outbound Proxy
     Should be **YES**
@@ -82,7 +82,7 @@ Term Proxy Transport Protocol
     Should be **TLS**
 
 Term Outbound Proxy
-    Shoyld be **subdomain.teams.example.com**
+    Should be **subdomain.teams.example.com**
 
 Media Encryption Mode
     Should be **SRTP SDES**
@@ -122,7 +122,7 @@ Call routing
 =====================
 
 * Incoming call routing works as usual - call will be authenticated by customer auth matching logic, then routing will be done according to routing plan.
-* Outgount call routing works as usual - just create Dialpeer with MS Teams gateway and Yeti will send call to proper trunk.
+* Outgoing call routing works as usual - just create Dialpeer with MS Teams gateway and Yeti will send call to proper trunk.
 
 
 

diff --git a/en/cdr-export.rst b/en/cdr-export.rst
@@ -5,7 +5,7 @@
 CDR export configuration
 ========================
 
-CDR export feature allows operator to unload CDR from database to CSV file. Yeti uses `Postgresql COPY <https://www.postgresql.org/docs/current/sql-copy.html>`_ method for CSV generation, so the file will be saved by postgresql daemon.
+CDR export feature allows operator to unload CDR from database to CSV file. Yeti uses `PostgreSQL COPY <https://www.postgresql.org/docs/current/sql-copy.html>`_ method for CSV generation, so the file will be saved by PostgreSQL daemon.
 
 .. figure:: cdr-export-download.png
 

diff --git a/en/conf.py b/en/conf.py
@@ -26,10 +26,13 @@
 # If your documentation needs a minimal Sphinx version, state it here.
 # needs_sphinx = '1.0'
 
-# Add any Sphinx extension module names here, as strings. They can be
-# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
-# ones.
-extensions = ["sphinx.ext.graphviz", "sphinx.ext.mathjax", "sphinxcontrib.mermaid", "sphinxcontrib.googleanalytics", "sphinxcontrib.video"]
+extensions = ["sphinx.ext.graphviz", "sphinx.ext.mathjax", "sphinxcontrib.mermaid", "sphinxcontrib.googleanalytics", "sphinxcontrib.video", "sphinxcontrib.spelling"]
+
+spelling_lang = 'en_US'
+tokenizer_lang = 'en_US'
+spelling_show_suggestions = True
+spelling_ignore_acronyms = True
+spelling_word_list_filename = ['spelling_wordlist.txt']
 
 # Add any paths that contain templates here, relative to this directory.
 templates_path = ["_templates"]
@@ -307,5 +310,3 @@
 googleanalytics_id = "G-1YGEQV43K8"
 
 mermaid_version = "11.4.1"
-
-
diff --git a/en/database-tuning.rst b/en/database-tuning.rst
@@ -1,13 +1,17 @@
 .. :maxdepth: 2
+
+.. spelling:word-list::
+    postgresql
+
 .. _database_tuning:
 
 ============================
 Databases performance tuning
 ============================
 
-By default Postgresql RDBMS configured to consume minimal system resources. This approach allows Postgresql to start on any server after installation. YETI as well as any other system uses Postgresql requires changing default configuration in order to archive best performance.
+By default PostgreSQL RDBMS configured to consume minimal system resources. This approach allows PostgreSQL to start on any server after installation. YETI as well as any other system uses PostgreSQL requires changing default configuration in order to archive best performance.
 
-We recommends to change next configuration variables at /etc/postgresql/13/yeti/postgresql.conf
+We recommends to change next configuration variables at /etc/postgresql/16/yeti/postgresql.conf
 
 .. code-block:: ini
 
@@ -18,11 +22,11 @@ We recommends to change next configuration variables at /etc/postgresql/13/yeti/
 
 
 Set **shared_buffers** variable to 1/3 of total RAM installed to server if you share this server with some another application. For example we recommends install yeti-web on same server as routing database. 
-If your server is dedicated for postgresql set **shared_buffers** to 2/3 of your RAM.
+If your server is dedicated for PostgreSQL set **shared_buffers** to 2/3 of your RAM.
 
-When configuration changed you should restart your postgresql instance using `service postgresql restart`
+When configuration changed you should restart your PostgreSQL instance using `service postgresql restart`
 
-.. seealso:: Read Postgresql manual https://www.postgresql.org/docs/13/ to understand postgresql architecture and features
+.. seealso:: Read PostgreSQL manual https://www.postgresql.org/docs/16/ to understand RDBMS architecture and features
 
 
 

diff --git a/en/disconnect-codes.rst b/en/disconnect-codes.rst
@@ -120,7 +120,7 @@ Radius request error
 Invalid radius profile
     Invalid radius profile configured
 Invalid radius response
-    RADIUS responce has unexpected format
+    RADIUS response has unexpected format
 Radius reject
     RADIUS servers send Access-Reject
 
diff --git a/en/general.rst b/en/general.rst
@@ -14,11 +14,11 @@ YETI — class4 SIP softswitch with integrated billing and intelligent routing s
 Solution is intended to act as distributed SBC on the networks of the service providers which are working using protocol SIP.
 System supports a variety of intelligent routing algorithms.
 
-Softswitch handles SIP signalling and RTP traffic. Supports transcoding, detailed CDRs (more than 100 fields) allows to save all parameters which are needed for billing, debugging and analytic reports.
+Softswitch handles SIP signaling and RTP traffic. Supports transcoding, detailed CDRs (more than 100 fields) allows to save all parameters which are needed for billing, debugging and analytic reports.
 Yeti supports intelligent LCR/ASR/ACD routing by various criteria. Below is short list of supported features.
 
-Signalling and RTP processing
------------------------------
+Signaling and RTP processing
+----------------------------
 - SIP v.2.0 over UDP, TCP and TLS transports
 - IPv6 support. Flexible resolving configuration
 - SRTP with DTLS and SDES mechanisms
@@ -62,7 +62,7 @@ Authorization
 - DST, SRC prefixes
 - SIP R-URI domain
 - Custom SIP header
-- Geolocation of the signalling node
+- Geolocation of the signaling node
 - External RADIUS server
 
 Routing
@@ -71,7 +71,7 @@ Routing
 - Re-routing which is transparent for the client.
   Flexible configuration for the conditions when to use next route
 - Rewriting or transparent passing of the disconnect codes for the client
-- Flexible LCR configuration (quiality control, prices limit).
+- Flexible LCR configuration (quality control, prices limit).
   Possibility of the fast implementation of the any desired alternative algorithm
 - Capacity control for gateways, destinations, companies, accounts
 - Source and Destination number based Blacklisting and per number translation rules
@@ -88,18 +88,18 @@ Billing
 
 - Realtime CDR writing. Possibility to skip CDR write for specific disconnect codes
 - Realtime traffic blocking when balance limit reached
-- Flexible rateplanes configuration and routing policies to provide optimal profitability
+- Flexible rateplans configuration and routing policies to provide optimal profitability
 - Configurable billing intervals, support of the connect fee
 - Invoices and documents generation from templates
 - Dynamic price calculation for client from real termination price.
   This mode useful to   sell traffic for the trusted clients at the minimum cost price
 - Integration with external systems
-- Possibility to send CDRs to the external systems (e.g for antifraud analysis)
+- Possibility to send CDRs to the external systems (e.g for anti-fraud analysis)
 - REST API for data modification (in development)
 - Lawful interception sensors.
   Allows to configure traffic mirroring to the external equipment without affecting on system work.
   It's possible to configure different sensors for different call legs and gateways.
-  At this moment system supports IP-IP and IP over Ethernet incapsulation.
+  At this moment system supports IP-IP and IP over Ethernet encapsulation.
 - Support to receive information about upper limit for the rate for the each call from the custom SIP header from the client.
 - Ability to show information about real termination cost (supplier rates) to the trusted clients, and information about cost for the client ( useful in case of dynamic rate calculation)
 
@@ -122,7 +122,7 @@ Administration
   Such configuration is fault tolerant to the network and hardware issues, and provides correct CDR billing after reconnection between system parts.
 - Convenient web-interface with possibility to find simply any system entities. Interface operators modifications logging allows to provide a high level of security. Supported export and import for all system configuration base objects.
 - Time-consuming tasks are performed in background to prevent blocking of the web-interface.
-- All components are developed and packaged for single platform (Debian GNU/Linux) and can be setup/upgraded using standart package manager (apt).
+- All components are developed and packaged for single platform (Debian GNU/Linux) and can be setup/upgraded using system package manager (apt).
 - CLI interface for routing system. Allows to manage all routing nodes and use extended debugging tools.
 - Recording of the PCAP dumps for the calls to provide simple debugging. Recorded dumps are available through web-interface.
 - CDRs have big amount of the debugging info.
@@ -137,8 +137,8 @@ Yeti consists of the following components:
 
 - Switch server (SEMS + YETI module)
 - Incoming traffic balancer (Kamailio)
-- Routing database (Postgresql)
-- CDR database (Postgresql)
+- Routing database (PostgreSQL)
+- CDR database (PostgreSQL)
 - Realtime data storage(Redis)
 - Management Web-interface (RoR, ruby)
 - CLI interface (python) [optional]

diff --git a/en/installation/installation-1.12/cdr-database.rst b/en/installation/installation-1.12/cdr-database.rst
@@ -1,5 +1,7 @@
 .. :maxdepth: 2
 
+.. spelling:word-list::
+    postgresql
 
 ==========================
 CDR databases installation
@@ -17,7 +19,7 @@ CDRs databases require similar set of packages as routing database
     # apt update && apt install postgresql-13 postgresql-contrib-13 postgresql-13-prefix postgresql-13-pgq3 postgresql-13-pgq-ext postgresql-13-yeti postgresql-13-pllua pgqd
 
 
-.. warning:: It is important to install Postgresql from  `PGDG <https://wiki.postgresql.org/wiki/Apt>`_ repository. See :doc:`repositories` for details
+.. warning:: It is important to install PostgreSQL from  `PGDG <https://wiki.postgresql.org/wiki/Apt>`_ repository. See :doc:`repositories` for details
 
 
 

diff --git a/en/installation/installation-1.12/release-notes.rst b/en/installation/installation-1.12/release-notes.rst
@@ -30,7 +30,7 @@ Upgrading to 1.12.79
 
 In yeti-web version 1.12.79 asynchronous CDR statistics calculation was introduced. This new mechanism requires additional configuration after system upgrade.
 
-Enable CDR Stats add configutation for CDR stats process to **/opt/yeti-web/config/pgq_processors.yml**:
+Enable CDR Stats add configuration for CDR stats process to **/opt/yeti-web/config/pgq_processors.yml**:
 
 .. code-block:: yaml
 

diff --git a/en/installation/installation-1.12/routing-database.rst b/en/installation/installation-1.12/routing-database.rst
@@ -1,5 +1,7 @@
 .. :maxdepth: 2
 
+.. spelling:word-list::
+    postgresql
 
 =============================
 Routing database installation
@@ -11,7 +13,7 @@ Routing database installation
 Supported versions
 ------------------
 
-The only supported postgresql version is 13.
+The only supported PostgreSQL version is 13.
 
 
 Packages installation

diff --git a/en/installation/installation-1.12/web.rst b/en/installation/installation-1.12/web.rst
@@ -8,7 +8,7 @@ WEB interface installation
 Server requirements:
 
 - amd64 architecture
-- Debian 11 Bullseye distibution
+- Debian 11 Bullseye distribution
 - at least 4GB of RAM
 
 Packages installation

diff --git a/en/installation/installation-1.13/cdr-database.rst b/en/installation/installation-1.13/cdr-database.rst
@@ -1,5 +1,7 @@
 .. :maxdepth: 2
 
+.. spelling:word-list::
+    postgresql
 
 ==========================
 CDR databases installation
@@ -17,7 +19,7 @@ CDRs databases require similar set of packages as routing database
     # apt update && apt install postgresql-16 postgresql-contrib-16 postgresql-16-prefix postgresql-16-pgq3 postgresql-16-pgq-ext postgresql-16-yeti postgresql-16-pllua pgqd
 
 
-.. warning:: It is important to install Postgresql from  `PGDG <https://wiki.postgresql.org/wiki/Apt>`_ repository. See :doc:`repositories` for details
+.. warning:: It is important to install PostgreSQL from  `PGDG <https://wiki.postgresql.org/wiki/Apt>`_ repository. See :doc:`repositories` for details
 
 
 

diff --git a/en/installation/installation-1.13/release-notes.rst b/en/installation/installation-1.13/release-notes.rst
@@ -5,8 +5,8 @@ Release notes
 =============
 
     * Debian 12 support
-    * Postgresql 16 support
-    * Migration to new debian repo
+    * PostgreSQL 16 support
+    * Migration to new Debian repo
     * Ruby upgraded to 3.3.5
     * Improved privacy processing
     * Registrar scalability improvements

diff --git a/en/installation/installation-1.13/routing-database.rst b/en/installation/installation-1.13/routing-database.rst
@@ -1,5 +1,7 @@
 .. :maxdepth: 2
 
+.. spelling:word-list::
+    postgresql
 
 =============================
 Routing database installation
@@ -11,7 +13,7 @@ Routing database installation
 Supported versions
 ------------------
 
-The only supported postgresql version is 16.
+The only supported PostgreSQL version is 16.
 
 
 Packages installation

diff --git a/en/installation/installation-1.13/upgrade-from-1.12.rst b/en/installation/installation-1.13/upgrade-from-1.12.rst
@@ -18,10 +18,10 @@ Upgrade OS
 Upgrade Debian GNU/Linux to version 12.
 
 
-Upgrade Postgresql instances
+Upgrade PostgreSQL instances
 ----------------------------
 
-Upgrade routing and CDR databases instances from Postgresql 13 to Postgresql 16.
+Upgrade routing and CDR databases instances from PostgreSQL 13 to PostgreSQL 16.
 
 
 Upgrade yeti-web package

diff --git a/en/installation/installation-1.13/web.rst b/en/installation/installation-1.13/web.rst
@@ -8,7 +8,7 @@ WEB interface installation
 Server requirements:
 
 - amd64 architecture
-- Debian 12 Bookworm distibution
+- Debian 12 Bookworm distribution
 - at least 4GB of RAM
 
 Packages installation