modules: readme files regenerated - rtpengine ... [skip ci]

src/modules/rtpengine/README

@@ -52,7 +52,7 @@ Richard Fuchs
    1. Admin Guide
 
         1. Overview
-        2. Multiple RTP proxy usage
+        2. Usage With Multiple RTPEngine Instances
         3. Dependencies
 
               3.1. Kamailio Modules
@@ -249,7 +249,7 @@ Chapter 1. Admin Guide
    Table of Contents
 
    1. Overview
-   2. Multiple RTP proxy usage
+   2. Usage With Multiple RTPEngine Instances
    3. Dependencies
 
         3.1. Kamailio Modules
@@ -362,19 +362,19 @@ Chapter 1. Admin Guide
    however due to the incompatible control protocol, it only works with
    RTP proxies which specifically support it.
 
-2. Multiple RTP proxy usage
+2. Usage With Multiple RTPEngine Instances
 
-   The rtpengine module can support multiple RTP proxies for
+   The rtpengine module can support multiple RTPEngine instances for
    balancing/distribution and control/selection purposes.
 
-   The module allows definition of several sets of rtpproxies.
+   The module allows definition of several sets of RTPEngines.
    Load-balancing will be performed over a set and the admin has the
    ability to choose what set should be used. The set is selected via its
    id - the id being defined with the set. Refer to the “rtpengine_sock”
    module parameter definition for syntax description.
 
    The balancing inside a set is done automatically by the module based on
-   the weight of each RTP proxy from the set.
+   the weight of each RTPEngine from the set.
 
    The selection of the set is done from script prior using
    rtpengine_delete(), rtpengine_offer() or rtpengine_answer() functions -
@@ -395,11 +395,11 @@ Chapter 1. Admin Guide
    the set was selected using setid_avp, the avp needs to be set only once
    before rtpengine_offer() or rtpengine_manage() call.
 
-   From the current implementation point of view, the sets of rtpproxy
-   nodes are shared memory(shm), so all processes can see a common list of
-   nodes. There is no locking when setting the nodes enabled/disabled (to
-   keep the memory access as fast as possible). Thus, problems related to
-   node state might appear for concurrent processes that might set the
+   From the current implementation point of view, the sets of rtpengine
+   nodes are in shared memory(shm), so all processes can see a common list
+   of nodes. There is no locking when setting the nodes enabled/disabled
+   (to keep the memory access as fast as possible). Thus, problems related
+   to node state might appear for concurrent processes that might set the
    nodes enabled/disabled(e.g. by fifo command). This robustness problems
    are overcome as follows.
 
@@ -809,12 +809,12 @@ mysql> describe rtpengine;
 +----------+------------------+------+-----+---------------------+-------+
 
 mysql> select * from rtpengine;
-+-------+---------------------------+--------+----------+---------------------+
-| setid | url                       | weight | disabled | stamp               |
-+-------+---------------------------+--------+----------+---------------------+
-|     0 | udp:rtpproxy1.domain:8800 |      1 |        0 | 2016-03-10 10:30:54 |
-|     0 | udp:rtpproxy2.domain:8800 |      1 |        1 | 2016-03-10 10:30:54 |
-+-------+---------------------------+--------+----------+---------------------+
++-------+----------------------------+--------+----------+---------------------+
+| setid | url                        | weight | disabled | stamp               |
++-------+----------------------------+--------+----------+---------------------+
+|     0 | udp:rtpengine1.domain:8800 |      1 |        0 | 2016-03-10 10:30:54 |
+|     0 | udp:rtpengine2.domain:8800 |      1 |        1 | 2016-03-10 10:30:54 |
++-------+----------------------------+--------+----------+---------------------+
 
 mysql> select * from version;
 +---------------------------+---------------+