some fixes and PAI info (#164)

* some fixes and PAI info

en/conf.py

@@ -26,7 +26,14 @@
 # If your documentation needs a minimal Sphinx version, state it here.
 # needs_sphinx = '1.0'
 
-extensions = ["sphinx.ext.graphviz", "sphinx.ext.mathjax", "sphinxcontrib.mermaid", "sphinxcontrib.googleanalytics", "sphinxcontrib.video", "sphinxcontrib.spelling"]
+extensions = [
+	"sphinx.ext.graphviz",
+	"sphinx.ext.mathjax",
+	"sphinxcontrib.mermaid",
+	"sphinxcontrib.googleanalytics",
+	"sphinxcontrib.video",
+	"sphinxcontrib.spelling"
+]
 
 spelling_lang = 'en_US'
 tokenizer_lang = 'en_US'

en/quick-start/quick_start.rst

@@ -3,7 +3,7 @@
 Routing quick start guide
 =========================
 
-This document explains how to configure Yeti to route your fist test call.
+This document explains how to configure Yeti to route your first 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 :)
 
@@ -18,15 +18,15 @@ For configuration purposes :ref:`Yeti Web interface <web>` could be used.
 
 .. _quick_start_chapter1:
 
-Chapter 1.  Basic configuration
-===============================
+Basic configuration
+===================
 
 
 In this Chapter we'll configure Yeti for receiving calls on IP address **127.0.0.1** (any port, UDP) and switching them (in case if B-number starts from **380**) to the Gateway with IP address **128.0.0.1**.
 
 **Step 1. Creation of Contractors**
 
-At the first step it is necessary to configure two :ref:`Contractor's <contractors>` records: one with type :ref:`Customer <contractor_customer>` and second with type :ref:`Vendor <contractor_vendor>`. Both records should be *Enabled*.
+At the first step it is necessary to configure two :ref:`Contractors <contractors>`: one with type :ref:`Customer <contractor_customer>` and second with type :ref:`Vendor <contractor_vendor>`. Both contractors should be *Enabled*.
 
 
 .. table:: Example of records filling (only fields that should be changed from default values are shown)
@@ -43,12 +43,12 @@ At the first step it is necessary to configure two :ref:`Contractor's <contracto
 
 .. note::
 
-   It is possible to use one record instead two by enabling both (:ref:`Customer <contractor_customer>` and :ref:`Vendor <contractor_vendor>`) flags.
+   It is possible to use one Contractor instead two by enabling both (:ref:`Customer <contractor_customer>` and :ref:`Vendor <contractor_vendor>`) flags.
 
 
 **Step 2. Creation of Accounts**
 
-At the second step it is necessary to configure two :ref:`Account's <accounts>` records: one will be linked to Contractor A (Customer) and second will be linked to Contractor B (Vendor). You should also set *Max balance* parameter for the Vendor to the some value that allow to make a call (current balance will be less than *Max balance* value). In our example we'll set 100 monetary units.
+At the second step it is necessary to configure two :ref:`Accounts <accounts>`: one will be linked to Contractor A (Customer) and second will be linked to Contractor B (Vendor). You should also set *Max balance* parameter for the Vendor to the some value that allow to make a call (current balance will be less than *Max balance* value). In our example we'll set 100 monetary units.
 
 .. table:: Example of records filling (only fields that should be changed from default values are shown)
    :widths: auto
@@ -64,7 +64,7 @@ At the second step it is necessary to configure two :ref:`Account's <accounts>`
 
 **Step 3. Creation of Gateways**
 
-At the third step it is necessary to configure two :ref:`Gateway's <gateways>` records: one will be linked to Contractor A (Customer) and second will be linked to Contractor B (Vendor). Both records should be *Enabled*. It is also important to allow origination at the *Gateway A* and termination to the *Gateway B*.
+At the third step it is necessary to configure two :ref:`Gateways <gateways>`: one will be linked to Contractor A (Customer) and second will be linked to Contractor B (Vendor). Both records should be *Enabled*. It is also important to allow origination at the *Gateway A* and termination to the *Gateway B*.
 
 .. table:: Example of records filling (only fields that should be changed from default values are shown)
    :widths: auto
@@ -91,7 +91,7 @@ At the third step it is necessary to configure two :ref:`Gateway's <gateways>` r
 
 At the fourth step it is necessary to configure:
 
- - at least one :ref:`Routing Group's <routing_group>` record;
+ - at least one :ref:`Routing Group <routing_group>`;
 
    .. table:: Example of records filling
       :widths: auto
@@ -104,7 +104,7 @@ At the fourth step it is necessary to configure:
 
 
 
- - at least one :ref:`Routing Plan's <routing_plan>` record that is associated with :ref:`Routing Group <routing_group>` above;
+ - at least one :ref:`Routing Plan <routing_plan>` that is associated with :ref:`Routing Group <routing_group>` above;
 
    .. table:: Example of records filling (only fields that should be changed from default values are shown)
       :widths: auto
@@ -118,7 +118,7 @@ At the fourth step it is necessary to configure:
 
 
 
- - at least one :ref:`Dialpeer's <dialpeers>` record that should be associated with :ref:`Routing Group <routing_group>`, :ref:`Vendor <contractors>`, :ref:`Vendor's Account <accounts>` and :ref:`Vendor's Gateway <gateways>` that were configured above. In our example we use **380** (international code of Ukraine) as *Prefix* and we'll pay one monetary unit per minute to the Vendor after the initial interval (by default - 1 minute) and 2 monetary units during initial interval. This :ref:`Dialpeer <dialpeers>` will be used as a route for all traffic to Ukrainian numbers;
+ - at least one :ref:`Dialpeer <dialpeers>` that should be associated with :ref:`Routing Group <routing_group>`, :ref:`Vendor <contractors>`, :ref:`Vendor's Account <accounts>` and :ref:`Vendor's Gateway <gateways>` that were configured above. In our example we use **380** (international code of Ukraine) as *Prefix* and we'll pay one monetary unit per minute to the Vendor after the initial interval (by default - 1 second) and 2 monetary units during initial interval. This :ref:`Dialpeer <dialpeers>` will be used as a route for all traffic to Ukrainian numbers;
 
    .. table:: Example of records filling (only fields that should be changed from default values are shown)
       :widths: auto
@@ -142,7 +142,7 @@ At the fourth step it is necessary to configure:
 
 At the fifth step it is necessary to configure:
 
- - at least one :ref:`Rateplan's <rateplans>` record;
+ - at least one :ref:`Rateplan <rateplans>`;
 
    .. table:: Example of records filling (only fields that should be changed from default values are shown)
       :widths: auto
@@ -155,7 +155,7 @@ At the fifth step it is necessary to configure:
 
 
 
- - at least one :ref:`Destination's <destinations>` record that should be associated with with :ref:`Rateplan <rateplans>` above. In our example we also use **380** (international code of Ukraine) as *Prefix*  and we'll receive 1.5 monetary units per minute from Customer after the initial interval and 3 monetary units during initial interval. So, in case of call with ten minutes length the profit will be (3-2)+(10-1)*(1.5-1) = 5.5 monetary units (16.5 will be received from the Customer and 11 will be paid to the Vendor);
+ - at least one :ref:`Destination <destinations>` that should be associated with with :ref:`Rateplan <rateplans>` above. In our example we also use **380** (international code of Ukraine) as *Prefix*  and we'll receive 1.5 monetary units per minute from Customer after the initial interval and 3 monetary units during initial interval. So, in case of call with ten minutes length the profit will be (3-2)+(10-1)*(1.5-1) = 5.5 monetary units (16.5 will be received from the Customer and 11 will be paid to the Vendor);
 
    .. table:: Example of records filling (only fields that should be changed from default values are shown)
       :widths: auto
@@ -180,7 +180,7 @@ At the fifth step it is necessary to configure:
 
 **Step 6. Creation of Customer Auth**
 
-At the sixth step it is necessary to configure at least one :ref:`Customers Auth's <customer_auth>` record that should be associated with :ref:`Customer <contractors>`, :ref:`Customer's Account <accounts>` and :ref:`Customer's Gateway <gateways>`, :ref:`Rateplan <rateplans>` and :ref:`Routing Group <routing_group>` that were configured above.
+At the sixth step it is necessary to configure at least one :ref:`Customers Auth <customer_auth>` that should be associated with :ref:`Customer <contractors>`, :ref:`Customer's Account <accounts>` and :ref:`Customer's Gateway <gateways>`, :ref:`Rateplan <rateplans>` and :ref:`Routing Group <routing_group>` that were configured above.
 
 .. table:: Example of records filling (only fields that should be changed from default values are shown)
    :widths: auto
@@ -201,7 +201,7 @@ At the sixth step it is necessary to configure at least one :ref:`Customers Auth
 
 **Step 7. Test the call**
 
-At the last step it is necessary to create some :ref:`Payment's <payments>` record for topping up the balance of Account A and test the call (Customer's balance should be greater than *Min balance* value).
+At the last step it is necessary to create some :ref:`Payment <payments>` for topping up the balance of Account A and test the call (Customer's balance should be greater than *Min balance* value).
 
 .. table:: Example of records filling (only fields that should be changed from default values are shown)
    :widths: auto
@@ -235,12 +235,12 @@ As a result two records will be shown, where the first record is an actual recor
 
 .. _quick_start_chapter2:
 
-Chapter 2.  Additional Dialpeer
-===============================
+Additional Dialpeer
+===================
 
 In this Chapter we'll improve basic configuration that is described in :ref:`Chapter 1 <quick_start_chapter1>` above by adding new :ref:`Dialpeers <dialpeers>` that will help to spend less money for calling to the alternative routes.
 
-In our new example the same :ref:`Vendor <contractors>` (Contractor B from basic configuration) proposed us special price for all calls that will be made to the numbers that start from **38048** (regional code of Odessa city in Ukraine).
+In our new example the same :ref:`Vendor <contractors>` (Contractor B from basic configuration) proposed us special price for all calls that will be made to the numbers that start from **38048** (code of Odesa region in Ukraine).
 
 **Step 1. Creation of additional Dialpeer**
 
@@ -286,8 +286,8 @@ As a result two records will be shown, where the first record is an actual recor
 
 .. _quick_start_chapter3:
 
-Chapter 3.  Alternative Gateway for calls to the specific numbers
-=================================================================
+Alternative Gateway for calls to the specific numbers
+=====================================================
 
 In this Chapter we'll improve configuration that is described in :ref:`Chapter 1 <quick_start_chapter1>` above by adding new :ref:`Vendor's Gateway <gateways>` that will be used for terminating calls that are sent to the specific numbers (to the numbers that start from **38048705**).
 
@@ -358,8 +358,8 @@ As a result two records will be shown, where the first record is an actual recor
 
 .. _quick_start_chapter4:
 
-Chapter 4.  Origin based billing
-================================
+Origin based billing
+====================
 
 In this Chapter we'll improve configuration that is described in :ref:`Chapter 1 <quick_start_chapter1>` above by adding origin based billing. In our example we'll configure lower price (0.25 monetary unit per minute after the initial interval and 0.5 monetary units during initial interval) for calling to Ukraine (to the numbers that start from **380**) from France (from the numbers that start from **33**).
 
@@ -479,8 +479,8 @@ As a result two records will be shown, where the first record is an actual recor
 
 .. _quick_start_chapter5:
 
-Chapter 5.  Emergency calls
-===========================
+Emergency calls
+===============
 
 In this Chapter we'll change configuration that is described in :ref:`Chapter 1 <quick_start_chapter1>` above by adding possibility to make free call to the emergency number (**112**) even in case of zero balance of Customer's account.
 

en/spelling_wordlist.txt

@@ -109,6 +109,7 @@ Numberlists
 odt
 Ok
 ok
+Odesa
 Pai
 pai
 param

en/web-interface/cdr/cdr-history.rst

@@ -159,6 +159,8 @@ LegB Ruri
 Is Redirected
     Will be true if call leg B was redirected using 3xx SIP response or REFER request.
 
+.. _cdr_pai:
+
 Pai In
     Value of **P-Asserted-Identity** header received from origination gateway in initial INVITE on legA.
 

en/web-interface/equipment/gateways.rst

@@ -440,10 +440,32 @@ Diversion rewrite result
 
 
 PAI Send mode
-    TODO
-
+    Mode of **P-Asserted-Identity** header transmission to termination gateway. Available options:
+
+    - **Do not send** - Do not send **P-Asserted-Identity** header
+    - **Build TEL URI from Source Number** - Generate **P-Asserted-Identity** as `tel URI <https://datatracker.ietf.org/doc/html/rfc3966>`_ header using Source number as user-part.
+    - **Build SIP URI from Source Number** - Generate **P-Asserted-Identity** as **sip URI** header using Source number as user-part. **PAI Domain** should be defined.
+    - **Build SIP URI from Source Number with user=phone** - Generate **P-Asserted-Identity** as `sip URI with user=phone paramerer <https://datatracker.ietf.org/doc/html/rfc3261#section-19.1.6>`_ using Source number as user-part. **PAI Domain** should be defined.
+    - **Relay PAI/PPI as is** - Relay **P-Asserted-Identity** and **P-Preferred-Identity** headers from call legA.
+    - Relay PAI/PPI as TEL uri
+        Build **P-Asserted-Identity** and **P-Preferred-Identity** as `tel URI <https://datatracker.ietf.org/doc/html/rfc3966>`_  based on P-Asserted-Identity and P-Preferred-Identity received from call legA.
+
+        .. warning:: Experimental feature.  Disabled by default.
+
+    - Relay PAI/PPI as SIP uri
+        Build **P-Asserted-Identity** and **P-Preferred-Identity** as **sip URI**  based on P-Asserted-Identity and P-Preferred-Identity received from call legA. If PAI and PPI headers received on legA have sip URI format, domain will be preserved. Otherwise **PAI Domain** will be used.
+
+        .. warning:: Experimental feature.  Disabled by default.
+
+    - Relay PAI/PPI as SIP uri. Replace domain
+        Build **P-Asserted-Identity** and **P-Preferred-Identity** as **sip URI**  based on P-Asserted-Identity and P-Preferred-Identity received from call legA. Domain part will be replaced with **PAI Domain** value.
+
+        .. warning:: Experimental feature.  Disabled by default.
+
+    Modes that relays headers from call legA also require proper :ref:`PAI Policy <customers_auth_pai_policy>` configuration at CustomersAuth object. **P-Asserted-Identity** and **P-Preferred-Identity** values sent to termination gateway will be saved in :ref:`CDR attributes PAI Out and PPI OUT <cdr_pai>`
+
 PAI Domain
-    TODO
+    Domain part of **P-Asserted-Identity** and **P-Preferred-Identity** headers generated by **PAI Send mode** logic.
 
 Src name rewrite rule
     Regular expression pattern for From display-name part.

en/web-interface/index.rst

@@ -6,15 +6,12 @@ Admin WEB interface and  routing logic
 
 :Site: https://yeti-switch.org/
 
-.. warning::
-    Elements of configuration marked by symbol * should be filled.
-
 .. note::
 
     Default credentials to login on web-interface after software installation:
 
-    - *login*: **admin**,
-    - *password*: **111111**
+    *login*: **admin**
+    *password*: **111111**
 
 .. toctree::
    :maxdepth: 2

en/web-interface/routing/customers-auths.rst

@@ -150,8 +150,8 @@ After sorting of *Customer Auth* records routing procedure will be continued wit
 
 Customer Auth form contains few tabs and each one is described below.
 
-General **Customers Auth**'s attributes:
-````````````````````````````````````````
+General attributes
+``````````````````
 
     .. _customer_auth_id:
 
@@ -213,8 +213,8 @@ General **Customers Auth**'s attributes:
         If enabled, YETI adds the special SIP-header into 200 SIP-message, which contains
         current price for calls, in order to a Customer should be informed.
 
-Match condition **Customers Auth**'s options
-````````````````````````````````````````````
+Match condition options
+```````````````````````
     This part is crucial for authentication process of incoming calls. You should note that a one
     customer may have many of Customer Auth with almost the same parameters, so pay
     attention to parameters besides Ip address.
@@ -280,8 +280,8 @@ Match condition **Customers Auth**'s options
 
     .. _customers_auth_number_translation:
 
-Number translation **Customers Auth**'s options
-```````````````````````````````````````````````
+Number translation options
+``````````````````````````
 
     Diversion policy
         Defines what to do with Diversion header within SIP-signalization.
@@ -292,6 +292,29 @@ Number translation **Customers Auth**'s options
     Diversion rewrite result
         The result of changing a Diversion header, using the Rewrite Rule above.
         See :ref:`how to use POSIX Regular Expressions in Yeti <posix_regular_expressions2>`.
+
+    .. _customers_auth_pai_policy:
+
+    PAI Policy
+        **P-Asserted-Identity** and **P-Preferred-Identity** headers processing logic. Available options:
+
+        - Do not accept
+            Do not accept incoming **P-Asserted-Identity** and **P-Preferred-Identity** data. It will not be possible to relay PAI and PPI to termination gateway
+
+        - Accept
+            Accept incoming **P-Asserted-Identity** and **P-Preferred-Identity** data. It will be possible to relay PAI and PPI to termination gateway
+
+        - Require
+            Yeti will reject call if no **P-Asserted-Identity** header received from call originator
+
+        **P-Asserted-Identity** and **P-Preferred-Identity** values received from call originator will be saved in :ref:`CDR attributes PAI In and PPI In <cdr_pai>`
+
+    PAI Rewrite rule/PAI Rewrite result
+        Rewrite rules for **P-Asserted-Identity** and **P-Preferred-Identity** URI user-part.
+        See :ref:`how to use POSIX Regular Expressions in Yeti <posix_regular_expressions2>`.
+
+        .. warning:: Experimental feature.  Disabled by default.
+
     Src name rewrite rule
         This field should contain a regular expression for changing the Name field in the Source-number within SIP-signalization.
         See :ref:`how to use POSIX Regular Expressions in Yeti <posix_regular_expressions2>`.
@@ -313,8 +336,8 @@ Number translation **Customers Auth**'s options
 
     .. _radius_options:
 
-Radius **Customers Auth**'s options
-```````````````````````````````````
+Radius options
+``````````````
 
     Radius auth profile
         Must be specified if the additional radius authentication is required.
@@ -335,8 +358,8 @@ Radius **Customers Auth**'s options
 
     .. _routing_tags_options:
 
-Routing Tags **Customers Auth**'s options
-`````````````````````````````````````````
+Routing Tags options
+````````````````````
     Tag action
         Describes one of the possible actions that could be applied to the current set of :ref:`Routing Tags <routing_tag>` that are applied for the call with using *Tag action value* below. Usually *Authentication* it is first step where :ref:`Routing Tags <routing_tag>` can be added to the call. Following actions can be selected in this field:
 

en/yeti-client/installation.rst

@@ -4,11 +4,11 @@
 Installation
 ============
 
-Customer portal packed to Debian package **yeti-cli** and available for Debian 9 and Debian 10 distribution. To install it run:
+Customer portal distributed as Debian package **yeti-client** and available for Debian 12 distribution. To install it run:
 
 .. code-block:: console
 
 	# apt install yeti-client
 
-software will be installed to  **/opt/yeti-client**
+Software will be installed to  **/opt/yeti-client**