rtpengine Module

Maxim Sobolev

   Sippy Software, Inc.

Juha Heinanen

   TuTPro, Inc.

Edited by

Maxim Sobolev

Bogdan-Andrei Iancu

Juha Heinanen

Sas Ovidiu

Carsten Bock

   ng-voice GmbH

Richard Fuchs

   Sipwise GmbH

Donat Zenichev

   Sipwise GmbH

Joey Golan

   Copyright © 2003-2008 Sippy Software, Inc.

   Copyright © 2005 Voice Sistem SRL

   Copyright © 2009-2014 TuTPro Inc.

   Copyright © 2010 VoIPEmbedded Inc.

   Copyright © 2013-2019 Sipwise GmbH
     __________________________________________________________________

   Table of Contents

   1. Admin Guide

        1. Overview
        2. Recommended Version
        3. Usage With Multiple RTPEngine Instances
        4. Dependencies

              4.1. Kamailio Modules
              4.2. External Libraries or Applications

        5. Parameters

              5.1. rtpengine_sock (string)
              5.2. rtpengine_disable_tout (integer)
              5.3. aggressive_redetection (integer)
              5.4. rtpengine_tout_ms (integer)
              5.5. rtpengine_allow_op (integer)
              5.6. queried_nodes_limit (integer)
              5.7. rtpengine_retr (integer)
              5.8. extra_id_pv (string)
              5.9. setid_avp (string)
              5.10. force_send_interface (string)
              5.11. read_sdp_pv (string)
              5.12. write_sdp_pv (string)
              5.13. write_sdp_pv_mode (int)
              5.14. rtp_inst_pvar (string)
              5.15. hash_table_size (integer)
              5.16. hash_table_tout (integer)
              5.17. db_url (string)
              5.18. table_name (string)
              5.19. setid_col (string)
              5.20. url_col (string)
              5.21. weight_col (string)
              5.22. disabled_col (string)
              5.23. setid_default (integer)
              5.24. media_duration (string)
              5.25. mos_min_pv (string)
              5.26. mos_min_at_pv (string)
              5.27. mos_min_packetloss_pv (string)
              5.28. mos_min_jitter_pv (string)
              5.29. mos_min_roundtrip_pv (string)
              5.30. mos_max_pv (string)
              5.31. mos_max_at_pv (string)
              5.32. mos_max_packetloss_pv (string)
              5.33. mos_max_jitter_pv (string)
              5.34. mos_max_roundtrip_pv (string)
              5.35. mos_average_pv (string)
              5.36. mos_average_packetloss_pv (string)
              5.37. mos_average_jitter_pv (string)
              5.38. mos_average_roundtrip_pv (string)
              5.39. mos_average_samples_pv (string)
              5.40. mos_A_label_pv (string)
              5.41. mos_min_A_pv (string)
              5.42. mos_min_at_A_pv (string)
              5.43. mos_min_packetloss_A_pv (string)
              5.44. mos_min_jitter_A_pv (string)
              5.45. mos_min_roundtrip_A_pv (string)
              5.46. mos_min_roundtrip_leg_A_pv (string)
              5.47. mos_max_A_pv (string)
              5.48. mos_max_at_A_pv (string)
              5.49. mos_max_packetloss_A_pv (string)
              5.50. mos_max_jitter_A_pv (string)
              5.51. mos_max_roundtrip_A_pv (string)
              5.52. mos_max_roundtrip_leg_A_pv (string)
              5.53. mos_average_A_pv (string)
              5.54. mos_average_packetloss_A_pv (string)
              5.55. mos_average_jitter_A_pv (string)
              5.56. mos_average_roundtrip_A_pv (string)
              5.57. mos_average_roundtrip_leg_A_pv (string)
              5.58. mos_average_samples_A_pv (string)
              5.59. mos_B_label_pv (string)
              5.60. mos_min_B_pv (string)
              5.61. mos_min_at_B_pv (string)
              5.62. mos_min_packetloss_B_pv (string)
              5.63. mos_min_jitter_B_pv (string)
              5.64. mos_min_roundtrip_B_pv (string)
              5.65. mos_min_roundtrip_leg_B_pv (string)
              5.66. mos_max_B_pv (string)
              5.67. mos_max_at_B_pv (string)
              5.68. mos_max_packetloss_B_pv (string)
              5.69. mos_max_jitter_B_pv (string)
              5.70. mos_max_roundtrip_B_pv (string)
              5.71. mos_max_roundtrip_leg_B_pv (string)
              5.72. mos_average_B_pv (string)
              5.73. mos_average_packetloss_B_pv (string)
              5.74. mos_average_jitter_B_pv (string)
              5.75. mos_average_roundtrip_B_pv (string)
              5.76. mos_average_roundtrip_leg_B_pv (string)
              5.77. mos_average_samples_B_pv (string)
              5.78. dtmf_event_callid (string)
              5.79. dtmf_event_source_tag (string)
              5.80. dtmf_event_timestamp (string)
              5.81. dtmf_event (string)
              5.82. control_cmd_tos (integer)
              5.83. hash_algo (integer)
              5.84. wsapi (string)
              5.85. dtmf_events_sock (string)
              5.86. ping_mode (integer)

        6. ping_interval (integer)
        7. enable_dmq (integer)
        8. dtmf_event_source_label (str)
        9. dtmf_event_tags (str)
        10. dtmf_event_type (str)
        11. dtmf_event_source_ip (str)
        12. dtmf_event_duration (str)
        13. dtmf_event_volume (str)
        14. event_callback (str)
        15. Functions

              15.1. set_rtpengine_set(setid[, setid])
              15.2. rtpengine_offer([flags][,via-branch])
              15.3. rtpengine_answer([flags][,via-branch])
              15.4. rtpengine_info([flags][,via-branch])
              15.5. rtpengine_delete([flags][,via-branch])
              15.6. rtpengine_destroy([flags][,via-branch])
              15.7. rtpengine_query([flags][,via-branch])
              15.8. rtpengine_query_v(fmt, var)
              15.9. rtpengine_connect([flags][,via-branch])
              15.10. rtpengine_manage([flags][,via-branch])
              15.11.
                      rtpengine_subscribe_request(flags,sdp_avp,to_tag_avp,s
                      tream_xavp[,via-branch])

              15.12. rtpengine_subscribe_answer([flags][,via-branch])
              15.13. rtpengine_unsubscribe([flags][,via-branch])
              15.14. start_recording([flags])
              15.15. stop_recording([flags])
              15.16. block_dtmf([flags])
              15.17. unblock_dtmf([flags])
              15.18. block_media([flags])
              15.19. unblock_media([flags])
              15.20. silence_media([flags])
              15.21. unsilence_media([flags])
              15.22. start_forwarding([flags])
              15.23. stop_forwarding([flags])
              15.24. play_media([flags])
              15.25. stop_media([flags])
              15.26. play_dtmf([flags])

        16. Exported Pseudo Variables

              16.1. $rtpestat
              16.2. $rtpstat

        17. RPC Commands

              17.1. rtpengine.reload
              17.2. rtpengine.enable proxy_url/all 0/1
              17.3. rtpengine.show proxy_url/all
              17.4. rtpengine.ping proxy_url/all
              17.5. rtpengine.get_hash_total

        18. Event routes

              18.1. rtpengine:dtmf-event

   2. Frequently Asked Questions

   List of Examples

   1.1. Set rtpengine_sock parameter
   1.2. Set rtpengine_disable_tout parameter
   1.3. Set aggressive_redetection parameter
   1.4. Set rtpengine_tout_ms parameter
   1.5. Set rtpengine_allow_op parameter
   1.6. Set queried_nodes_limit parameter
   1.7. Set rtpengine_retr parameter
   1.8. Set extra_id_pv parameter
   1.9. Set setid_avp parameter
   1.10. Set force_send_interface parameter
   1.11. Set read_sdp_pv parameter
   1.12. Set write_sdp_pv parameter
   1.13. Set write_sdp_pv_mode parameter
   1.14. Set rtp_inst_pvar parameter
   1.15. Set hash_table_size parameter
   1.16. Set hash_table_tout parameter
   1.17. Set db_url parameter
   1.18. Set table_name parameter
   1.19. Se tup rtpengine table
   1.20. Set setid_col parameter
   1.21. Set url_col parameter
   1.22. Set weight_col parameter
   1.23. Set disabled_col parameter
   1.24. Set setid_default parameter
   1.25. Set media_duration parameter
   1.26. Set mos_min_pv parameter
   1.27. Set mos_min_at_pv parameter
   1.28. Set mos_min_packetloss_pv parameter
   1.29. Set mos_min_jitter_pv parameter
   1.30. Set mos_min_roundtrip_pv parameter
   1.31. Set mos_max_pv parameter
   1.32. Set mos_max_at_pv parameter
   1.33. Set mos_max_packetloss_pv parameter
   1.34. Set mos_max_jitter_pv parameter
   1.35. Set mos_max_roundtrip_pv parameter
   1.36. Set mos_average_pv parameter
   1.37. Set mos_average_packetloss_pv parameter
   1.38. Set mos_average_jitter_pv parameter
   1.39. Set mos_average_roundtrip_pv parameter
   1.40. Set mos_average_samples_pv parameter
   1.41. Set mos_A_label_pv parameter
   1.42. Set mos_min_A_pv parameter
   1.43. Set mos_min_at_A_pv parameter
   1.44. Set mos_min_packetloss_A_pv parameter
   1.45. Set mos_min_jitter_A_pv parameter
   1.46. Set mos_min_roundtrip_A_pv parameter
   1.47. Set mos_min_roundtrip_leg_A_pv parameter
   1.48. Set mos_max_A_pv parameter
   1.49. Set mos_max_at_A_pv parameter
   1.50. Set mos_max_packetloss_A_pv parameter
   1.51. Set mos_max_jitter_A_pv parameter
   1.52. Set mos_max_roundtrip_A_pv parameter
   1.53. Set mos_max_roundtrip_leg_A_pv parameter
   1.54. Set mos_average_A_pv parameter
   1.55. Set mos_average_packetloss_A_pv parameter
   1.56. Set mos_average_jitter_A_pv parameter
   1.57. Set mos_average_roundtrip_A_pv parameter
   1.58. Set mos_average_roundtrip_leg_A_pv parameter
   1.59. Set mos_average_samples_A_pv parameter
   1.60. Set mos_B_label_pv parameter
   1.61. Set mos_min_B_pv parameter
   1.62. Set mos_min_at_B_pv parameter
   1.63. Set mos_min_packetloss_B_pv parameter
   1.64. Set mos_min_jitter_B_pv parameter
   1.65. Set mos_min_roundtrip_B_pv parameter
   1.66. Set mos_min_roundtrip_leg_B_pv parameter
   1.67. Set mos_max_B_pv parameter
   1.68. Set mos_max_at_B_pv parameter
   1.69. Set mos_max_packetloss_B_pv parameter
   1.70. Set mos_max_jitter_B_pv parameter
   1.71. Set mos_max_roundtrip_B_pv parameter
   1.72. Set mos_max_roundtrip_leg_B_pv parameter
   1.73. Set mos_average_B_pv parameter
   1.74. Set mos_average_packetloss_B_pv parameter
   1.75. Set mos_average_jitter_B_pv parameter
   1.76. Set mos_average_roundtrip_B_pv parameter
   1.77. Set mos_average_roundtrip_leg_B_pv parameter
   1.78. Set mos_average_samples_B_pv parameter
   1.79. Set dtmf_event_callid parameter
   1.80. Set dtmf_event_source_tag parameter
   1.81. Set dtmf_event_timestamp parameter
   1.82. Set dtmf_event parameter
   1.83. Set control_cmd_tos parameter
   1.84. Set hash_algo parameter
   1.85. Set wsapi parameter
   1.86. Set dtmf_events_sock parameter
   1.87. Set ping_mode parameter
   1.88. Set ping_interval parameter
   1.89. Set enable_dmq parameter
   1.90. set_rtpengine_set usage
   1.91. rtpengine_offer usage
   1.92. rtpengine_offer usage to force transcoding from opus to PCMU
   1.93. rtpengine_offer usage of via-branch parameter
   1.94. rtpengine_answer usage
   1.95. rtpengine_info usage
   1.96. rtpengine_delete usage
   1.97. rtpengine_destroy usage
   1.98. rtpengine_query usage
   1.99. rtpengine_query_v usage
   1.100. rtpengine_connect usage
   1.101. rtpengine_manage usage
   1.102. rtpengine_subscribe_request usage
   1.103. rtpengine_subscribe_answer usage
   1.104. rtpengine_unsubscribe usage
   1.105. start_recording usage
   1.106. stop_recording usage
   1.107. block_dtmf usage
   1.108. unblock_dtmf usage
   1.109. block_media usage
   1.110. unblock_media usage
   1.111. silence_media usage
   1.112. unsilence_media usage
   1.113. start_forwarding usage
   1.114. stop_forwarding usage
   1.115. play_media usage
   1.116. stop_media usage
   1.117. play_dtmf usage
   1.118. $rtpestat Usage
   1.119. rtpengine.reload usage
   1.120. rtpengine.enable usage
   1.121. rtpengine.show usage
   1.122. rtpengine.ping usage
   1.123. rtpengine.get_hash_total usage

Chapter 1. Admin Guide

   Table of Contents

   1. Overview
   2. Recommended Version
   3. Usage With Multiple RTPEngine Instances
   4. Dependencies

        4.1. Kamailio Modules
        4.2. External Libraries or Applications

   5. Parameters

        5.1. rtpengine_sock (string)
        5.2. rtpengine_disable_tout (integer)
        5.3. aggressive_redetection (integer)
        5.4. rtpengine_tout_ms (integer)
        5.5. rtpengine_allow_op (integer)
        5.6. queried_nodes_limit (integer)
        5.7. rtpengine_retr (integer)
        5.8. extra_id_pv (string)
        5.9. setid_avp (string)
        5.10. force_send_interface (string)
        5.11. read_sdp_pv (string)
        5.12. write_sdp_pv (string)
        5.13. write_sdp_pv_mode (int)
        5.14. rtp_inst_pvar (string)
        5.15. hash_table_size (integer)
        5.16. hash_table_tout (integer)
        5.17. db_url (string)
        5.18. table_name (string)
        5.19. setid_col (string)
        5.20. url_col (string)
        5.21. weight_col (string)
        5.22. disabled_col (string)
        5.23. setid_default (integer)
        5.24. media_duration (string)
        5.25. mos_min_pv (string)
        5.26. mos_min_at_pv (string)
        5.27. mos_min_packetloss_pv (string)
        5.28. mos_min_jitter_pv (string)
        5.29. mos_min_roundtrip_pv (string)
        5.30. mos_max_pv (string)
        5.31. mos_max_at_pv (string)
        5.32. mos_max_packetloss_pv (string)
        5.33. mos_max_jitter_pv (string)
        5.34. mos_max_roundtrip_pv (string)
        5.35. mos_average_pv (string)
        5.36. mos_average_packetloss_pv (string)
        5.37. mos_average_jitter_pv (string)
        5.38. mos_average_roundtrip_pv (string)
        5.39. mos_average_samples_pv (string)
        5.40. mos_A_label_pv (string)
        5.41. mos_min_A_pv (string)
        5.42. mos_min_at_A_pv (string)
        5.43. mos_min_packetloss_A_pv (string)
        5.44. mos_min_jitter_A_pv (string)
        5.45. mos_min_roundtrip_A_pv (string)
        5.46. mos_min_roundtrip_leg_A_pv (string)
        5.47. mos_max_A_pv (string)
        5.48. mos_max_at_A_pv (string)
        5.49. mos_max_packetloss_A_pv (string)
        5.50. mos_max_jitter_A_pv (string)
        5.51. mos_max_roundtrip_A_pv (string)
        5.52. mos_max_roundtrip_leg_A_pv (string)
        5.53. mos_average_A_pv (string)
        5.54. mos_average_packetloss_A_pv (string)
        5.55. mos_average_jitter_A_pv (string)
        5.56. mos_average_roundtrip_A_pv (string)
        5.57. mos_average_roundtrip_leg_A_pv (string)
        5.58. mos_average_samples_A_pv (string)
        5.59. mos_B_label_pv (string)
        5.60. mos_min_B_pv (string)
        5.61. mos_min_at_B_pv (string)
        5.62. mos_min_packetloss_B_pv (string)
        5.63. mos_min_jitter_B_pv (string)
        5.64. mos_min_roundtrip_B_pv (string)
        5.65. mos_min_roundtrip_leg_B_pv (string)
        5.66. mos_max_B_pv (string)
        5.67. mos_max_at_B_pv (string)
        5.68. mos_max_packetloss_B_pv (string)
        5.69. mos_max_jitter_B_pv (string)
        5.70. mos_max_roundtrip_B_pv (string)
        5.71. mos_max_roundtrip_leg_B_pv (string)
        5.72. mos_average_B_pv (string)
        5.73. mos_average_packetloss_B_pv (string)
        5.74. mos_average_jitter_B_pv (string)
        5.75. mos_average_roundtrip_B_pv (string)
        5.76. mos_average_roundtrip_leg_B_pv (string)
        5.77. mos_average_samples_B_pv (string)
        5.78. dtmf_event_callid (string)
        5.79. dtmf_event_source_tag (string)
        5.80. dtmf_event_timestamp (string)
        5.81. dtmf_event (string)
        5.82. control_cmd_tos (integer)
        5.83. hash_algo (integer)
        5.84. wsapi (string)
        5.85. dtmf_events_sock (string)
        5.86. ping_mode (integer)

   6. ping_interval (integer)
   7. enable_dmq (integer)
   8. dtmf_event_source_label (str)
   9. dtmf_event_tags (str)
   10. dtmf_event_type (str)
   11. dtmf_event_source_ip (str)
   12. dtmf_event_duration (str)
   13. dtmf_event_volume (str)
   14. event_callback (str)
   15. Functions

        15.1. set_rtpengine_set(setid[, setid])
        15.2. rtpengine_offer([flags][,via-branch])
        15.3. rtpengine_answer([flags][,via-branch])
        15.4. rtpengine_info([flags][,via-branch])
        15.5. rtpengine_delete([flags][,via-branch])
        15.6. rtpengine_destroy([flags][,via-branch])
        15.7. rtpengine_query([flags][,via-branch])
        15.8. rtpengine_query_v(fmt, var)
        15.9. rtpengine_connect([flags][,via-branch])
        15.10. rtpengine_manage([flags][,via-branch])
        15.11.
                rtpengine_subscribe_request(flags,sdp_avp,to_tag_avp,stream_
                xavp[,via-branch])

        15.12. rtpengine_subscribe_answer([flags][,via-branch])
        15.13. rtpengine_unsubscribe([flags][,via-branch])
        15.14. start_recording([flags])
        15.15. stop_recording([flags])
        15.16. block_dtmf([flags])
        15.17. unblock_dtmf([flags])
        15.18. block_media([flags])
        15.19. unblock_media([flags])
        15.20. silence_media([flags])
        15.21. unsilence_media([flags])
        15.22. start_forwarding([flags])
        15.23. stop_forwarding([flags])
        15.24. play_media([flags])
        15.25. stop_media([flags])
        15.26. play_dtmf([flags])

   16. Exported Pseudo Variables

        16.1. $rtpestat
        16.2. $rtpstat

   17. RPC Commands

        17.1. rtpengine.reload
        17.2. rtpengine.enable proxy_url/all 0/1
        17.3. rtpengine.show proxy_url/all
        17.4. rtpengine.ping proxy_url/all
        17.5. rtpengine.get_hash_total

   18. Event routes

        18.1. rtpengine:dtmf-event

1. Overview

   This is a module that enables media streams to be proxied via an RTP
   proxy. The only RTP proxy currently known to work with this module is
   Sipwise rtpengine. The rtpengine module is a modified version of the
   original rtpproxy module using a new control protocol. The module is
   designed to be a drop-in replacement for the old module from a
   configuration file point of view, however due to the incompatible
   control protocol, it only works with RTP proxies which specifically
   support it.

2. Recommended Version

   This control module is compatible with a wide range of versions of
   Sipwise rtpengine. The version numbers follow the schema “mrXX.Y.ZZZ”,
   with “XX” being the major release number, “Y” the minor release number,
   and “ZZZ” the patch level suffix. Releases with “Y” equalling 5 are LTS
   releases and receive bug fixes for several years. The recommended
   version therefore is either the latest LTS release on the latest patch
   level (e.g. “mr12.5.1.46”), or the latest non-LTS release if newer
   features are desired (e.g. “mr13.4.1.5”). This version of Kamailio
   includes a field in the control protocol which is not supported by
   versions of rtpengine older than “mr12.4” and will trigger a warning
   log message in these older versions. This is purely cosmetic.

3. Usage With Multiple RTPEngine Instances

   The rtpengine module can support multiple RTPEngine instances for
   balancing/distribution and control/selection purposes.

   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 RTPEngine from the set. The default weight is 1, if
   another RTPEngine should be used twice as often as the first one, one
   would specify the weight 2 for this server, for example.

   The selection of the set is done from script prior using
   rtpengine_delete(), rtpengine_offer(), rtpengine_answer() or
   rtpengine_manage() functions - see the set_rtpengine_set() function.

   Another way to select the set is to define setid_avp module parameter
   and assign setid to the defined avp before calling rtpengine_offer() or
   rtpengine_manage() function. If forwarding of the requests fails and
   there is another branch to try, remember to unset the avp after calling
   rtpengine_delete() function.

   For backward compatibility reasons, a set with no id take by default
   the id 0. Also if no set is explicitly set before rtpengine_delete(),
   rtpengine_offer() or rtpengine_answer() the 0 id set will be used.

   IMPORTANT: if you use multiple sets, take care and use the same set for
   both rtpengine_offer()/rtpengine_answer() and rtpengine_delete()!! If
   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 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). These robustness
   problems are overcome as follows.

   If the current process sees the selected node as disabled, the node is
   force tested before the current process actually accepts the disabled
   state. If the test succeeds, the process will set the node as enabled
   (but other concurrent process might still see it as disabled).

   If the current process sees the selected node as enabled, it does no
   additional checks and sends the command which will fail in case the
   machine is actually broken. The process will set the node as disabled
   (but other concurrent process might still see it as enabled).

   The 'kamctl fifo' commands (including rtpengine ones) are executed by
   an exclusive process which operate on the same shared memory node list.

   All the nodes are pinged in the beginning by all the processes, even if
   the node list is shared memory.

4. Dependencies

   4.1. Kamailio Modules
   4.2. External Libraries or Applications

4.1. Kamailio Modules

   The following modules must be loaded before this module:
     * tm module - (optional) if you want to have rtpengine_manage() fully
       functional
     * lwsc module - (optional) if you plan to use “wsapi” parameter

4.2. External Libraries or Applications

   The following libraries or applications must be installed before
   running Kamailio with this module loaded:
     * None.

5. Parameters

   5.1. rtpengine_sock (string)
   5.2. rtpengine_disable_tout (integer)
   5.3. aggressive_redetection (integer)
   5.4. rtpengine_tout_ms (integer)
   5.5. rtpengine_allow_op (integer)
   5.6. queried_nodes_limit (integer)
   5.7. rtpengine_retr (integer)
   5.8. extra_id_pv (string)
   5.9. setid_avp (string)
   5.10. force_send_interface (string)
   5.11. read_sdp_pv (string)
   5.12. write_sdp_pv (string)
   5.13. write_sdp_pv_mode (int)
   5.14. rtp_inst_pvar (string)
   5.15. hash_table_size (integer)
   5.16. hash_table_tout (integer)
   5.17. db_url (string)
   5.18. table_name (string)
   5.19. setid_col (string)
   5.20. url_col (string)
   5.21. weight_col (string)
   5.22. disabled_col (string)
   5.23. setid_default (integer)
   5.24. media_duration (string)
   5.25. mos_min_pv (string)
   5.26. mos_min_at_pv (string)
   5.27. mos_min_packetloss_pv (string)
   5.28. mos_min_jitter_pv (string)
   5.29. mos_min_roundtrip_pv (string)
   5.30. mos_max_pv (string)
   5.31. mos_max_at_pv (string)
   5.32. mos_max_packetloss_pv (string)
   5.33. mos_max_jitter_pv (string)
   5.34. mos_max_roundtrip_pv (string)
   5.35. mos_average_pv (string)
   5.36. mos_average_packetloss_pv (string)
   5.37. mos_average_jitter_pv (string)
   5.38. mos_average_roundtrip_pv (string)
   5.39. mos_average_samples_pv (string)
   5.40. mos_A_label_pv (string)
   5.41. mos_min_A_pv (string)
   5.42. mos_min_at_A_pv (string)
   5.43. mos_min_packetloss_A_pv (string)
   5.44. mos_min_jitter_A_pv (string)
   5.45. mos_min_roundtrip_A_pv (string)
   5.46. mos_min_roundtrip_leg_A_pv (string)
   5.47. mos_max_A_pv (string)
   5.48. mos_max_at_A_pv (string)
   5.49. mos_max_packetloss_A_pv (string)
   5.50. mos_max_jitter_A_pv (string)
   5.51. mos_max_roundtrip_A_pv (string)
   5.52. mos_max_roundtrip_leg_A_pv (string)
   5.53. mos_average_A_pv (string)
   5.54. mos_average_packetloss_A_pv (string)
   5.55. mos_average_jitter_A_pv (string)
   5.56. mos_average_roundtrip_A_pv (string)
   5.57. mos_average_roundtrip_leg_A_pv (string)
   5.58. mos_average_samples_A_pv (string)
   5.59. mos_B_label_pv (string)
   5.60. mos_min_B_pv (string)
   5.61. mos_min_at_B_pv (string)
   5.62. mos_min_packetloss_B_pv (string)
   5.63. mos_min_jitter_B_pv (string)
   5.64. mos_min_roundtrip_B_pv (string)
   5.65. mos_min_roundtrip_leg_B_pv (string)
   5.66. mos_max_B_pv (string)
   5.67. mos_max_at_B_pv (string)
   5.68. mos_max_packetloss_B_pv (string)
   5.69. mos_max_jitter_B_pv (string)
   5.70. mos_max_roundtrip_B_pv (string)
   5.71. mos_max_roundtrip_leg_B_pv (string)
   5.72. mos_average_B_pv (string)
   5.73. mos_average_packetloss_B_pv (string)
   5.74. mos_average_jitter_B_pv (string)
   5.75. mos_average_roundtrip_B_pv (string)
   5.76. mos_average_roundtrip_leg_B_pv (string)
   5.77. mos_average_samples_B_pv (string)
   5.78. dtmf_event_callid (string)
   5.79. dtmf_event_source_tag (string)
   5.80. dtmf_event_timestamp (string)
   5.81. dtmf_event (string)
   5.82. control_cmd_tos (integer)
   5.83. hash_algo (integer)
   5.84. wsapi (string)
   5.85. dtmf_events_sock (string)
   5.86. ping_mode (integer)

5.1. rtpengine_sock (string)

   Definition of socket(s) used to connect to (a set) RTP proxy. It may
   specify an IPv4/IPv6 UDP socket or a websocket URI.

   Default value is “NONE” (disabled).

   Example 1.1. Set rtpengine_sock parameter
...
# single rtproxy
modparam("rtpengine", "rtpengine_sock", "udp:localhost:12221")
# IPv6 UDP
modparam("rtpengine", "rtpengine_sock", "udp6:localhost:12221")
# websocket
modparam("rtpengine", "rtpengine_sock", "ws://localhost:12221/")
# websocket with TLS
modparam("rtpengine", "rtpengine_sock", "wss://localhost:12221/")
# multiple rtproxies for LB with weights (missing weight defaults to 1)
modparam("rtpengine", "rtpengine_sock",
        "udp:localhost:12221=2 udp:localhost:12222=1")
# multiple sets of multiple rtproxies
modparam("rtpengine", "rtpengine_sock",
        "1 == udp:localhost:12221 udp:localhost:12222")
modparam("rtpengine", "rtpengine_sock",
        "2 == udp:localhost:12225")
...

5.2. rtpengine_disable_tout (integer)

   Once an RTP proxy was found unreachable and marked as disabled, the
   rtpengine module will not attempt to establish communication to that
   RTP proxy for rtpengine_disable_tout seconds.

   Default value is “60”.

   Can be set at runtime, e.g.:
                        $ kamcmd cfg.set_now_int rtpengine rtpengine_disable_tou
t 20

   Example 1.2. Set rtpengine_disable_tout parameter
...
modparam("rtpengine", "rtpengine_disable_tout", 20)
...

5.3. aggressive_redetection (integer)

   This parameter determines what happens when all potential rtpengines
   are found to be unreachable. If enabled, the sip server will send pings
   to all rtpengines, else no rtpengine will be queried until its
   rtpengine_disable_tout timeout passes.

   Default value is “0” (disabled).

   Can be set at runtime, e.g.:
                        $ kamcmd cfg.set_now_int rtpengine aggressive_redetectio
n 1

   Example 1.3. Set aggressive_redetection parameter
...
modparam("rtpengine", "aggressive_redetection", 1)
...

5.4. rtpengine_tout_ms (integer)

   Timeout value expressed in milliseconds in waiting for reply from RTP
   proxy.

   Default value is “1000”.

   Can be set at runtime, e.g.:
                        $ kamcmd cfg.set_now_int rtpengine rtpengine_tout_ms 100
0

   Example 1.4. Set rtpengine_tout_ms parameter
...
modparam("rtpengine", "rtpengine_tout_ms", 2000)
...

5.5. rtpengine_allow_op (integer)

   Enable this setting to allow finishing the current sessions while
   denying new sessions for deactivated nodes.

   Nodes can be manually deactivated via kamctl command i.e.
   "disabled(permanent)" nodes. Probably the manually deactivated machine
   is still running (did not crash).

   This is useful when deactivating a node for maintenance and reject new
   sessions but allow current ones to finish.

   The behaviour is the same for a rtpengine deleted table node. When the
   node is deleted from the table and the table reloaded (see
   nh_reload_rtpp) the node actually is disabled(permanent) and hidden for
   display. Next time the same node will be added in the table, and the
   database content reloaded, the re-activated node will be updated and
   re-displayed.

   Default value is “0” to keep the current behaviour.

   If value set to “1” it will send commands to all disabled nodes for the
   existing call.

   If value set to “2” it will send commands only to manually disabled
   nodes. (Not when timeout is disabled or node broken)

   Example 1.5. Set rtpengine_allow_op parameter
...
modparam("rtpengine", "rtpengine_allow_op", 1)
...

5.6. queried_nodes_limit (integer)

   The total number of nodes inside a set (sets are configurable via
   rtpengine_sock function) to be queried before giving up establishing a
   session. This brings more flexibility in case checking all rtpengines
   would take too long. Max limit is 30.

   By default all nodes in a set are tried before giving up communicating
   with the rtpengines.

   Can be set at runtime, e.g.:
                        $ kamcmd cfg.set_now_int rtpengine queried_nodes_limit 5

   Example 1.6. Set queried_nodes_limit parameter
...
modparam("rtpengine", "queried_nodes_limit", 5)
...

5.7. rtpengine_retr (integer)

   How many times the module should retry to send and receive after
   timeout was generated.

   Default value is “5”.

   Can be set at runtime, e.g.:
                        $ kamcmd cfg.set_now_int rtpengine rtpengine_retr 5

   Example 1.7. Set rtpengine_retr parameter
...
modparam("rtpengine", "rtpengine_retr", 2)
...

5.8. extra_id_pv (string)

   The parameter sets the PV definition to use when the “via-branch”
   parameter is used on rtpengine_delete(), rtpengine_offer(),
   rtpengine_answer() or rtpengine_manage() command.

   Default is empty, the “via-branch” parameter may not be used then.

   Example 1.8. Set extra_id_pv parameter
...
modparam("rtpengine", "extra_id_pv", "$avp(extra_id)")
...

5.9. setid_avp (string)

   The parameter defines an AVP that, if set, determines which RTP proxy
   set rtpengine_offer(), rtpengine_answer(), rtpengine_delete(), and
   rtpengine_manage() functions use.

   There is no default value.

   Example 1.9. Set setid_avp parameter
...
modparam("rtpengine", "setid_avp", "$avp(setid)")
...

5.10. force_send_interface (string)

   Forces all control messages between the SIP proxy and the RTP proxy to
   be sent from the specified local interface. Both IPv4 and IPv6
   addresses are supported. If not specified, the default interface
   selected by the operating system will be used. Note: when
   rtpengine_sock is an IPv6 link-local address, one _must_ set this
   parameter in order to successfully connect to RTP engine. This is
   necessarily because OS needs additional scope_id hint to communicate
   over IPv6 link locals. The scope_id is resolved based on the given
   IPv6.

   There is no default value.

   Example 1.10. Set force_send_interface parameter
...
modparam("rtpengine", "force_send_interface", "10.3.7.123")
modparam("rtpengine", "force_send_interface", "2001:8d8:1ff:10c0:9a90:96ff:fea8:
fd99")
...

5.11. read_sdp_pv (string)

   If this parameter is set to a valid AVP or script var specifier,
   rtpengine will take the input SDP from this pv instead of the message
   body.

   There is no default value.

   Example 1.11. Set read_sdp_pv parameter
...
modparam("rtpengine", "read_sdp_pv", "$var(sdp)")
...
request_route {
        ...
        $var(sdp) = $rb + "a=foo:bar\r\n";
        rtpengine_manage();
}

5.12. write_sdp_pv (string)

   If this parameter is set to a valid AVP or script var specifier, the
   SDP returned by rtpengine in the offer/answer operations is returned in
   the specified variable instead of the message body.

   There is no default value.

   Example 1.12. Set write_sdp_pv parameter
...
modparam("rtpengine", "write_sdp_pv", "$avp(sdp)")
...
request_route {
        ...
        rtpengine_manage();
        set_body("$avp(sdp)a=baz123\r\n", "application/sdp");
}

5.13. write_sdp_pv_mode (int)

   If this parameter is set to 1, the returned SDP is written to pv and
   also set to message body.

   Default value: 0 (write SDP only to pv).

   Example 1.13. Set write_sdp_pv_mode parameter
...
modparam("rtpengine", "write_sdp_pv", "$avp(sdp)")
modparam("rtpengine", "write_sdp_pv_mode", 1)
...
request_route {
        ...
        rtpengine_manage();
        xinfo("new sdp: $avp(sdp)\n");
}

5.14. rtp_inst_pvar (string)

   A pseudo variable to store the chosen RTP Engine URI. If this parameter
   is set, the URI of the instance chosen will be stored in the given
   variable.

   By default, this parameter is not set.

   Example 1.14. Set rtp_inst_pvar parameter
...
modparam("rtpengine", "rtp_inst_pvar", "$avp(RTP_INSTANCE)")
...

5.15. hash_table_size (integer)

   To maintain information about a selected rtp machine node for a given
   call, entries are added in a hashtable of (callid, node) pairs. This
   parameter sets the size of the hash table. Default value is 256.

   NOTE: If configured size is less than 1, the size will be defaulted to
   1.

   Example 1.15. Set hash_table_size parameter
...
modparam("rtpengine", "hash_table_size", 123)
...

5.16. hash_table_tout (integer)

   Number of seconds after an rtpengine hash table entry is marked for
   deletion. By default, this parameter is set to 3600 (seconds).

   To maintain information about a selected rtp machine node for a given
   call, entries are added in a hashtable of (callid, node) pairs. When
   command comes the callid is looked up in this table. If found, the
   chosen node is used. If not found, choose a new node, insert the callid
   in the hashtable and return the chosen node.

   NOTE: In the current implementation, the actual deletion happens on the
   fly, while insert/remove/lookup the hastable, only for the entries in
   the insert/remove/lookup path.

   NOTE: When configuring this parameter, one should consider maximum call
   time VS shared memory for unfinished calls.

   Example 1.16. Set hash_table_tout parameter
...
modparam("rtpengine", "hash_table_tout", 300)
...

5.17. db_url (string)

   The rtpengine database url. If present and valid, it activates database
   mode. In this mode the node information is read from database, not from
   configuration modparam parameters.

   By default, the database url is NULL (not set).

   Example 1.17. Set db_url parameter
...
modparam("rtpengine", "db_url", "mysql://pass@localhost/db")
...

5.18. table_name (string)

   The rtpengine table name. If database mode is activated (i.e. valid
   db_url), sets the name of the rtpengine table, on startup.

   By default, the rtpengine table name is "rtpengine".

   NOTE: One needs to add the version of the rtpengine table in the
   version table. The current version is version 1.

   Example 1.18. Set table_name parameter
...
modparam("rtpengine", "table_name", "rtpengine_table_name")
...

   Example 1.19. Se tup rtpengine table
mysql> describe rtpengine;
+----------+------------------+------+-----+---------------------+-------+
| Field    | Type             | Null | Key | Default             | Extra |
+----------+------------------+------+-----+---------------------+-------+
| setid    | int(10) unsigned | NO   | PRI | 0                   |       |
| url      | varchar(64)      | NO   | PRI | NULL                |       |
| weight   | int(10) unsigned | NO   |     | 1                   |       |
| disabled | int(1)           | NO   |     | 0                   |       |
| stamp    | datetime         | NO   |     | 1900-01-01 00:00:01 |       |
+----------+------------------+------+-----+---------------------+-------+

mysql> select * from rtpengine;
+-------+----------------------------+--------+----------+---------------------+
| 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;
+---------------------------+---------------+
| table_name                | table_version |
+---------------------------+---------------+
| rtpengine                 |             1 |
+---------------------------+---------------+

5.19. setid_col (string)

   Column name for the "setid" in the rtpengine table. If database mode is
   activated (i.e. valid db_url), set the setid of rtp nodes according to
   this column, on startup. The MySQL value for this column should be INT
   UNSIGNED.

   By default, the column name is "setid".

   Example 1.20. Set setid_col parameter
...
modparam("rtpengine", "setid_col", "setid_column_name")
...

5.20. url_col (string)

   Column name for the url in the rtpengine table. If database mode is
   activated (i.e. valid db_url), set the url of rtp nodes according to
   this column, on startup. The MySQL value for this column should be
   VARCHAR.

   By default, the column name is "url".

   Example 1.21. Set url_col parameter
...
modparam("rtpengine", "url_col", "url_column_name")
...

5.21. weight_col (string)

   Column name for weight in the rtpengine table. If database mode is
   activated (i.e. valid db_url), set the weight of rtp nodes according to
   this column, on startup. The column value has priority over the URL
   weight. The MySQL value for this column should be INT UNSIGNED.

   By default, the column name is "weight".

   Example 1.22. Set weight_col parameter
...
modparam("rtpengine", "weight_col", "weight_column_name")
...

5.22. disabled_col (string)

   Column name in the rtpengine table. If database mode is activated (i.e.
   valid db_url), set the state of rtp nodes according to this column, on
   startup. The MySQL value for this column should be INT.

   By default, the column name is "disabled".

   Example 1.23. Set disabled_col parameter
...
modparam("rtpengine", "disabled_col", "disabled_column_name")
...

5.23. setid_default (integer)

   The default set of nodes to be used.

   By default, the setid is 0.

   NOTE that if setid_avp is configured, this value will be ignored and
   the active set will be chosen according to the setid_avp.

   Example 1.24. Set setid_default parameter
...
modparam("rtpengine", "setid_default", 11)
...

5.24. media_duration (string)

   The name of a pseudovariable to be filled in with the length of the
   media being played back after a call to “play_media”, expressed in
   milliseconds. It's set to -1 if the length of the media could not be
   determined.

   By default, this parameter is not set.

   Example 1.25. Set media_duration parameter
...
modparam("rtpengine", "media_duration", "$avp(MEDIA_DURATION)")
...

5.25. mos_min_pv (string)

   The name of a pseudovariable to hold the minimum encountered MOS (Mean
   Opinion Score) value for the call. The value typically has a range of
   1.0 through 5.0.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Example 1.26. Set mos_min_pv parameter
...
modparam("rtpengine", "mos_min_pv", "$avp(mos_min)")
...

5.26. mos_min_at_pv (string)

   The name of a pseudovariable to hold the timestamp of when the minimum
   MOS value was encountered during the call, such as “0:30” for 30
   seconds after the start of the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Example 1.27. Set mos_min_at_pv parameter
...
modparam("rtpengine", "mos_min_at_pv", "$avp(mos_min_at)")
...

5.27. mos_min_packetloss_pv (string)

   The name of a pseudovariable to hold the amount of packetloss in
   percent at the time the minimum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Example 1.28. Set mos_min_packetloss_pv parameter
...
modparam("rtpengine", "mos_min_packetloss_pv", "$avp(mos_min_packetloss)")
...

5.28. mos_min_jitter_pv (string)

   The name of a pseudovariable to hold the amount of jitter in
   milliseconds at the time the minimum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Example 1.29. Set mos_min_jitter_pv parameter
...
modparam("rtpengine", "mos_min_jitter_pv", "$avp(mos_min_jitter)")
...

5.29. mos_min_roundtrip_pv (string)

   The name of a pseudovariable to hold the packet round-trip time in
   microseconds at the time the minimum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Example 1.30. Set mos_min_roundtrip_pv parameter
...
modparam("rtpengine", "mos_min_roundtrip_pv", "$avp(mos_min_roundtrip)")
...

5.30. mos_max_pv (string)

   The name of a pseudovariable to hold the maximum encountered MOS value
   for the call. The value typically has a range of 1.0 through 5.0.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Example 1.31. Set mos_max_pv parameter
...
modparam("rtpengine", "mos_max_pv", "$avp(mos_max)")
...

5.31. mos_max_at_pv (string)

   The name of a pseudovariable to hold the timestamp of when the maximum
   MOS value was encountered during the call, such as “0:30” for 30
   seconds after the start of the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Example 1.32. Set mos_max_at_pv parameter
...
modparam("rtpengine", "mos_max_at_pv", "$avp(mos_max_at)")
...

5.32. mos_max_packetloss_pv (string)

   The name of a pseudovariable to hold the amount of packetloss in
   percent at the time the maximum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Example 1.33. Set mos_max_packetloss_pv parameter
...
modparam("rtpengine", "mos_max_packetloss_pv", "$avp(mos_max_packetloss)")
...

5.33. mos_max_jitter_pv (string)

   The name of a pseudovariable to hold the amount of jitter in
   milliseconds at the time the maximum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Example 1.34. Set mos_max_jitter_pv parameter
...
modparam("rtpengine", "mos_max_jitter_pv", "$avp(mos_max_jitter)")
...

5.34. mos_max_roundtrip_pv (string)

   The name of a pseudovariable to hold the packet round-trip time in
   microseconds at the time the maximum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Example 1.35. Set mos_max_roundtrip_pv parameter
...
modparam("rtpengine", "mos_max_roundtrip_pv", "$avp(mos_max_roundtrip)")
...

5.35. mos_average_pv (string)

   The name of a pseudovariable to hold the average (median) MOS value for
   the call. The value typically has a range of 1.0 through 5.0.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Example 1.36. Set mos_average_pv parameter
...
modparam("rtpengine", "mos_average_pv", "$avp(mos_average)")
...

5.36. mos_average_packetloss_pv (string)

   The name of a pseudovariable to hold the average (median) amount of
   packetloss in percent present throughout the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Example 1.37. Set mos_average_packetloss_pv parameter
...
modparam("rtpengine", "mos_average_packetloss_pv", "$avp(mos_average_packetloss)
")
...

5.37. mos_average_jitter_pv (string)

   The name of a pseudovariable to hold the average (median) amount of
   jitter in milliseconds present throughout the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Example 1.38. Set mos_average_jitter_pv parameter
...
modparam("rtpengine", "mos_average_jitter_pv", "$avp(mos_average_jitter)")
...

5.38. mos_average_roundtrip_pv (string)

   The name of a pseudovariable to hold the average (median) packet
   round-trip time in milliseconds present throughout the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Example 1.39. Set mos_average_roundtrip_pv parameter
...
modparam("rtpengine", "mos_average_roundtrip_pv", "$avp(mos_average_roundtrip)")
...

5.39. mos_average_samples_pv (string)

   The name of a pseudovariable to hold the number of samples used to
   determine the other “average” MOS data points.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Example 1.40. Set mos_average_samples_pv parameter
...
modparam("rtpengine", "mos_average_samples_pv", "$avp(mos_average_samples)")
...

5.40. mos_A_label_pv (string)

   The name of a pseudovariable to hold a custom label used in rtpengine
   signalling. If set, all the statistics pseudovariables with the “_A”
   suffix will be filled in with statistics only from the call legs that
   match the label given in this variable. You need to fill this variable
   before invoking “rtpengine_delete”, “rtpengine_query”, or
   “rtpengine_manage”. Variable value should match the label= flag on
   “rtpengine_offer”, “rtpengine_answer”, or “rtpengine_manage”.

   There is no default value.

   Example 1.41. Set mos_A_label_pv parameter
...
modparam("rtpengine", "mos_A_label_pv", "$avp(mos_A_label)")
...

5.41. mos_min_A_pv (string)

   The name of a pseudovariable to hold the minimum encountered MOS value
   for the call. The value typically has a range of 1.0 through 5.0.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.42. Set mos_min_A_pv parameter
...
modparam("rtpengine", "mos_min_A_pv", "$avp(mos_min_A)")
...

5.42. mos_min_at_A_pv (string)

   The name of a pseudovariable to hold the timestamp of when the minimum
   MOS value was encountered during the call, such as “0:30” for 30
   seconds after the start of the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.43. Set mos_min_at_A_pv parameter
...
modparam("rtpengine", "mos_min_at_A_pv", "$avp(mos_min_at_A)")
...

5.43. mos_min_packetloss_A_pv (string)

   The name of a pseudovariable to hold the amount of packetloss in
   percent at the time the minimum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.44. Set mos_min_packetloss_A_pv parameter
...
modparam("rtpengine", "mos_min_packetloss_A_pv", "$avp(mos_min_packetloss_A)")
...

5.44. mos_min_jitter_A_pv (string)

   The name of a pseudovariable to hold the amount of jitter in
   milliseconds at the time the minimum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.45. Set mos_min_jitter_A_pv parameter
...
modparam("rtpengine", "mos_min_jitter_A_pv", "$avp(mos_min_jitter_A)")
...

5.45. mos_min_roundtrip_A_pv (string)

   The name of a pseudovariable to hold the packet round-trip time in
   microseconds at the time the minimum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.46. Set mos_min_roundtrip_A_pv parameter
...
modparam("rtpengine", "mos_min_roundtrip_A_pv", "$avp(mos_min_roundtrip_A)")
...

5.46. mos_min_roundtrip_leg_A_pv (string)

   The name of a pseudovariable to hold the packet round-trip time of the
   specific call leg in microseconds at the time the minimum MOS value was
   encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.47. Set mos_min_roundtrip_leg_A_pv parameter
...
modparam("rtpengine", "mos_min_roundtrip_leg_A_pv", "$avp(mos_min_roundtrip_leg_
A)")
...

5.47. mos_max_A_pv (string)

   The name of a pseudovariable to hold the maximum encountered MOS value
   for the call. The value typically has a range of 1.0 through 5.0.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.48. Set mos_max_A_pv parameter
...
modparam("rtpengine", "mos_max_A_pv", "$avp(mos_max_A)")
...

5.48. mos_max_at_A_pv (string)

   The name of a pseudovariable to hold the timestamp of when the maximum
   MOS value was encountered during the call, such as “0:30” for 30
   seconds after the start of the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.49. Set mos_max_at_A_pv parameter
...
modparam("rtpengine", "mos_max_at_A_pv", "$avp(mos_max_at_A)")
...

5.49. mos_max_packetloss_A_pv (string)

   The name of a pseudovariable to hold the amount of packetloss in
   percent at the time the maximum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.50. Set mos_max_packetloss_A_pv parameter
...
modparam("rtpengine", "mos_max_packetloss_A_pv", "$avp(mos_max_packetloss_A)")
...

5.50. mos_max_jitter_A_pv (string)

   The name of a pseudovariable to hold the amount of jitter in
   milliseconds at the time the maximum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.51. Set mos_max_jitter_A_pv parameter
...
modparam("rtpengine", "mos_max_jitter_A_pv", "$avp(mos_max_jitter_A)")
...

5.51. mos_max_roundtrip_A_pv (string)

   The name of a pseudovariable to hold the packet round-trip time in
   microseconds at the time the maximum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.52. Set mos_max_roundtrip_A_pv parameter
...
modparam("rtpengine", "mos_max_roundtrip_A_pv", "$avp(mos_max_roundtrip_A)")
...

5.52. mos_max_roundtrip_leg_A_pv (string)

   The name of a pseudovariable to hold the packet round-trip time of the
   specific call leg in microseconds at the time the maximum MOS value was
   encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.53. Set mos_max_roundtrip_leg_A_pv parameter
...
modparam("rtpengine", "mos_max_roundtrip_leg_A_pv", "$avp(mos_max_roundtrip_leg_
A)")
...

5.53. mos_average_A_pv (string)

   The name of a pseudovariable to hold the average (median) MOS value for
   the call. The value typically has a range of 1.0 through 5.0.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.54. Set mos_average_A_pv parameter
...
modparam("rtpengine", "mos_average_A_pv", "$avp(mos_average_A)")
...

5.54. mos_average_packetloss_A_pv (string)

   The name of a pseudovariable to hold the average (median) amount of
   packetloss in percent present throughout the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.55. Set mos_average_packetloss_A_pv parameter
...
modparam("rtpengine", "mos_average_packetloss_A_pv", "$avp(mos_average_packetlos
s_A)")
...

5.55. mos_average_jitter_A_pv (string)

   The name of a pseudovariable to hold the average (median) amount of
   jitter in milliseconds present throughout the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.56. Set mos_average_jitter_A_pv parameter
...
modparam("rtpengine", "mos_average_jitter_A_pv", "$avp(mos_average_jitter_A)")
...

5.56. mos_average_roundtrip_A_pv (string)

   The name of a pseudovariable to hold the average (median) packet
   round-trip time in microseconds present throughout the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.57. Set mos_average_roundtrip_A_pv parameter
...
modparam("rtpengine", "mos_average_roundtrip_A_pv", "$avp(mos_average_roundtrip_
A)")
...

5.57. mos_average_roundtrip_leg_A_pv (string)

   The name of a pseudovariable to hold the average (median) packet
   round-trip time of the specific call leg in microseconds present
   throughout the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.58. Set mos_average_roundtrip_leg_A_pv parameter
...
modparam("rtpengine", "mos_average_roundtrip_leg_A_pv", "$avp(mos_average_roundt
rip_leg_A)")
...

5.58. mos_average_samples_A_pv (string)

   The name of a pseudovariable to hold the number of samples used to
   determine the other “average” MOS data points.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.59. Set mos_average_samples_A_pv parameter
...
modparam("rtpengine", "mos_average_samples_A_pv", "$avp(mos_average_samples_A)")
...

5.59. mos_B_label_pv (string)

   The name of a pseudovariable to hold a custom label used in rtpengine
   signalling. If set, all the statistics pseudovariables with the “_B”
   suffix will be filled in with statistics only from the call legs that
   match the label given in this variable. You need to fill this variable
   before invoking “rtpengine_delete”, “rtpengine_query”, or
   “rtpengine_manage”. Variable value should match the label= flag on
   “rtpengine_offer”, “rtpengine_answer”, or “rtpengine_manage”.

   There is no default value.

   Example 1.60. Set mos_B_label_pv parameter
...
modparam("rtpengine", "mos_B_label_pv", "$avp(mos_B_label)")
...

5.60. mos_min_B_pv (string)

   The name of a pseudovariable to hold the minimum encountered MOS value
   for the call. The value typically has a range of 1.0 through 5.0.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.61. Set mos_min_B_pv parameter
...
modparam("rtpengine", "mos_min_B_pv", "$avp(mos_min_B)")
...

5.61. mos_min_at_B_pv (string)

   The name of a pseudovariable to hold the timestamp of when the minimum
   MOS value was encountered during the call, such as “0:30” for 30
   seconds after the start of the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.62. Set mos_min_at_B_pv parameter
...
modparam("rtpengine", "mos_min_at_B_pv", "$avp(mos_min_at_B)")
...

5.62. mos_min_packetloss_B_pv (string)

   The name of a pseudovariable to hold the amount of packetloss in
   percent at the time the minimum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.63. Set mos_min_packetloss_B_pv parameter
...
modparam("rtpengine", "mos_min_packetloss_B_pv", "$avp(mos_min_packetloss_B)")
...

5.63. mos_min_jitter_B_pv (string)

   The name of a pseudovariable to hold the amount of jitter in
   milliseconds at the time the minimum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.64. Set mos_min_jitter_B_pv parameter
...
modparam("rtpengine", "mos_min_jitter_B_pv", "$avp(mos_min_jitter_B)")
...

5.64. mos_min_roundtrip_B_pv (string)

   The name of a pseudovariable to hold the packet round-trip time in
   microseconds at the time the minimum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.65. Set mos_min_roundtrip_B_pv parameter
...
modparam("rtpengine", "mos_min_roundtrip_B_pv", "$avp(mos_min_roundtrip_B)")
...

5.65. mos_min_roundtrip_leg_B_pv (string)

   The name of a pseudovariable to hold the packet round-trip time of the
   specific call leg in microseconds at the time the minimum MOS value was
   encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.66. Set mos_min_roundtrip_leg_B_pv parameter
...
modparam("rtpengine", "mos_min_roundtrip_leg_B_pv", "$avp(mos_min_roundtrip_leg_
B)")
...

5.66. mos_max_B_pv (string)

   The name of a pseudovariable to hold the maximum encountered MOS value
   for the call. The value typically has a range of 1.0 through 5.0.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.67. Set mos_max_B_pv parameter
...
modparam("rtpengine", "mos_max_B_pv", "$avp(mos_max_B)")
...

5.67. mos_max_at_B_pv (string)

   The name of a pseudovariable to hold the timestamp of when the maximum
   MOS value was encountered during the call, such as “0:30” for 30
   seconds after the start of the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.68. Set mos_max_at_B_pv parameter
...
modparam("rtpengine", "mos_max_at_B_pv", "$avp(mos_max_at_B)")
...

5.68. mos_max_packetloss_B_pv (string)

   The name of a pseudovariable to hold the amount of packetloss in
   percent at the time the maximum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.69. Set mos_max_packetloss_B_pv parameter
...
modparam("rtpengine", "mos_max_packetloss_B_pv", "$avp(mos_max_packetloss_B)")
...

5.69. mos_max_jitter_B_pv (string)

   The name of a pseudovariable to hold the amount of jitter in
   milliseconds at the time the maximum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.70. Set mos_max_jitter_B_pv parameter
...
modparam("rtpengine", "mos_max_jitter_B_pv", "$avp(mos_max_jitter_B)")
...

5.70. mos_max_roundtrip_B_pv (string)

   The name of a pseudovariable to hold the packet round-trip time in
   microseconds at the time the maximum MOS value was encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.71. Set mos_max_roundtrip_B_pv parameter
...
modparam("rtpengine", "mos_max_roundtrip_B_pv", "$avp(mos_max_roundtrip_B)")
...

5.71. mos_max_roundtrip_leg_B_pv (string)

   The name of a pseudovariable to hold the packet round-trip time of the
   specific call leg in microseconds at the time the maximum MOS value was
   encountered;

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_A_label_pv” will be used in calculating this statistics value.

   Example 1.72. Set mos_max_roundtrip_leg_B_pv parameter
...
modparam("rtpengine", "mos_max_roundtrip_leg_B_pv", "$avp(mos_max_roundtrip_leg_
B)")
...

5.72. mos_average_B_pv (string)

   The name of a pseudovariable to hold the average (median) MOS value for
   the call. The value typically has a range of 1.0 through 5.0.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.73. Set mos_average_B_pv parameter
...
modparam("rtpengine", "mos_average_B_pv", "$avp(mos_average_B)")
...

5.73. mos_average_packetloss_B_pv (string)

   The name of a pseudovariable to hold the average (median) amount of
   packetloss in percent present throughout the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.74. Set mos_average_packetloss_B_pv parameter
...
modparam("rtpengine", "mos_average_packetloss_B_pv", "$avp(mos_average_packetlos
s_B)")
...

5.74. mos_average_jitter_B_pv (string)

   The name of a pseudovariable to hold the average (median) amount of
   jitter in milliseconds present throughout the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.75. Set mos_average_jitter_B_pv parameter
...
modparam("rtpengine", "mos_average_jitter_B_pv", "$avp(mos_average_jitter_B)")
...

5.75. mos_average_roundtrip_B_pv (string)

   The name of a pseudovariable to hold the average (median) packet
   round-trip time in microseconds present throughout the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.76. Set mos_average_roundtrip_B_pv parameter
...
modparam("rtpengine", "mos_average_roundtrip_B_pv", "$avp(mos_average_roundtrip_
B)")
...

5.76. mos_average_roundtrip_leg_B_pv (string)

   The name of a pseudovariable to hold the average (median) packet
   round-trip time of the specific call leg in microseconds present
   throughout the call.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.77. Set mos_average_roundtrip_leg_B_pv parameter
...
modparam("rtpengine", "mos_average_roundtrip_leg_B_pv", "$avp(mos_average_roundt
rip_leg_B)")
...

5.77. mos_average_samples_B_pv (string)

   The name of a pseudovariable to hold the number of samples used to
   determine the other “average” MOS data points.

   There is no default value.

   This value is filled in after invoking “rtpengine_delete”,
   “rtpengine_query”, or “rtpengine_manage” if the command resulted in a
   deletion of the call (or call branch).

   Only call legs matching the rtpengine label given in the
   “mos_B_label_pv” will be used in calculating this statistics value.

   Example 1.78. Set mos_average_samples_B_pv parameter
...
modparam("rtpengine", "mos_average_samples_B_pv", "$avp(mos_average_samples_B)")
...

5.78. dtmf_event_callid (string)

   The name of a pseudovariable to be filled in with the callid of the
   triggered dtmf event.

   By default, this parameter is not set.

   Example 1.79. Set dtmf_event_callid parameter
...
modparam("rtpengine", "dtmf_event_callid", "$avp(dtmf_event_callid)")
...

5.79. dtmf_event_source_tag (string)

   The name of a pseudovariable to be filled in with the source tag that
   triggered the dtmf event.

   By default, this parameter is not set.

   Example 1.80. Set dtmf_event_source_tag parameter
...
modparam("rtpengine", "dtmf_event_source_tag", "$avp(dtmf_event_source_tag)")
...

5.80. dtmf_event_timestamp (string)

   The name of a pseudovariable to be filled in with the timestamp when
   the dtmf event was triggered.

   By default, this parameter is not set.

   Example 1.81. Set dtmf_event_timestamp parameter
...
modparam("rtpengine", "dtmf_event_timestamp", "$avp(dtmf_event_timestamp)")
...

5.81. dtmf_event (string)

   The name of a pseudovariable to be filled in with the triggered DTMF
   value.

   By default, this parameter is not set.

   Example 1.82. Set dtmf_event parameter
...
modparam("rtpengine", "dtmf_event", "$avp(dtmf_event)")
...

5.82. control_cmd_tos (integer)

   The parameter is used to set the value of “type of service (tos)” for
   the control commands (such as rtpengine_offer(), rtpengine_answer()
   etc).

   There is no default value. By default this feature is not used.

   The values not falling into the range “0-255” will be simply ignored.

   Example 1.83. Set control_cmd_tos parameter
...
modparam("rtpengine", "control_cmd_tos", 144)
...

5.83. hash_algo (integer)

   The hashing algorithm to be used in node selection algorithm. There are
   two possibilities: SHA1 - 1 (calculate SHA1 hash over the Call-ID) or
   CRC32 - 2 (calculate crc32 sum over the callid). The legacy algorithm -
   0 is not available anymore. If 0 is specified the default CRC32 will be
   used.

   Default value is 2, CRC32.

   The values not falling into the range “0-2” are ignored.

   Example 1.84. Set hash_algo parameter
...
### use CRC32 instead of legacy algorithm
modparam("rtpengine", "hash_algo", 2)
...

5.84. wsapi (string)

   Configure a backend API for websocket usage. Currently the only
   supported setting is “lwsc” (libwebsockets). If unset, then the
   websocket protocol cannot be used.

   Example 1.85. Set wsapi parameter
...
modparam("rtpengine", "wsapi", "lwsc")
...

5.85. dtmf_events_sock (string)

   Definition of IPv4/IPv6 UDP socket used to receive dtmf events from
   RTPEngine.

   DTMF events coming from RTPEngine will trigger rtpengine:dtmf-event
   route.

   Default value is “NONE” (disabled).

   Example 1.86. Set dtmf_events_sock parameter
...
modparam("rtpengine", "dtmf_events_sock", "127.0.0.1:2223")
...

5.86. ping_mode (integer)

   Specify if the RTPEngine instances have to be pinged at startup to
   detect if they are active. Set it to 0 to disable pinging and to 1 to
   activate pinging.

   Default value is “1”.

   Example 1.87. Set ping_mode parameter
...
modparam("rtpengine", "ping_mode", 0)
...

6. ping_interval (integer)

   Specify the interval in seconds between pings to all rtpengines
   registered.

   Default value is “60”.

   Example 1.88. Set ping_interval parameter
...
modparam("rtpengine", "ping_interval", 10)
...

7. enable_dmq (integer)

   If set to 1, will enable DMQ replication of hashtable of (callid, node)
   pairs.

   Important: If this parameter is enabled, the DMQ module must be loaded
   first - otherwise, startup will fail.

   Default value is “0”.

   Example 1.89. Set enable_dmq parameter
...
modparam("rtpengine", "enable_dmq", 1)
...

8. dtmf_event_source_label (str)

9. dtmf_event_tags (str)

10. dtmf_event_type (str)

11. dtmf_event_source_ip (str)

12. dtmf_event_duration (str)

13. dtmf_event_volume (str)

14. event_callback (str)

15. Functions

   15.1. set_rtpengine_set(setid[, setid])
   15.2. rtpengine_offer([flags][,via-branch])
   15.3. rtpengine_answer([flags][,via-branch])
   15.4. rtpengine_info([flags][,via-branch])
   15.5. rtpengine_delete([flags][,via-branch])
   15.6. rtpengine_destroy([flags][,via-branch])
   15.7. rtpengine_query([flags][,via-branch])
   15.8. rtpengine_query_v(fmt, var)
   15.9. rtpengine_connect([flags][,via-branch])
   15.10. rtpengine_manage([flags][,via-branch])
   15.11.
          rtpengine_subscribe_request(flags,sdp_avp,to_tag_avp,stream_xavp[
          ,via-branch])

   15.12. rtpengine_subscribe_answer([flags][,via-branch])
   15.13. rtpengine_unsubscribe([flags][,via-branch])
   15.14. start_recording([flags])
   15.15. stop_recording([flags])
   15.16. block_dtmf([flags])
   15.17. unblock_dtmf([flags])
   15.18. block_media([flags])
   15.19. unblock_media([flags])
   15.20. silence_media([flags])
   15.21. unsilence_media([flags])
   15.22. start_forwarding([flags])
   15.23. stop_forwarding([flags])
   15.24. play_media([flags])
   15.25. stop_media([flags])
   15.26. play_dtmf([flags])

15.1.  set_rtpengine_set(setid[, setid])

   Sets the ID of the RTP proxy set to be used for the next
   rtpengine_delete(), rtpengine_offer(), rtpengine_answer() or
   rtpengine_manage() command. The parameter can be an integer or a config
   variable holding an integer.

   A second set ID can be specified to daisy-chain two RTP proxies. The
   two set IDs must be distinct from each other and there must not be any
   overlap in the proxies present in both sets. In this use case, the
   request (offer, answer, etc) is first sent to an RTP proxy from the
   first set, which rewrites the SDP body and sends it back to the module.
   The rewritten SDP body is then used to make another request to an RTP
   proxy from the second set, which rewrites the SDP body another time and
   sends it back to the module to be placed back into the SIP message.
   This is useful if you have a set of RTP proxies that the caller must
   use, and another distinct set of RTP proxies that the callee must use.

   This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE,
   BRANCH_ROUTE.

   Example 1.90. set_rtpengine_set usage
...
set_rtpengine_set("2");
rtpengine_offer();
...

15.2.  rtpengine_offer([flags][,via-branch])

   Rewrites SDP body to ensure that media is passed through an RTP proxy.
   To be invoked on INVITE for the cases the SDP bodies are in INVITE and
   200 OK and on 200 OK when SDP bodies are in 200 OK and ACK.

   The function will return true on success and false (-1) on various
   failures, like using rtp_engine_offer() on a SIP MESSAGE request or
   communication with rtpengine fails.

   Meaning of the parameters is as follows:
     * flags - flags to turn on some features.
       The “flags” string is a list of space-separated items. Each item is
       either an individual token, or a token in “key=value” format. The
       possible tokens are described below.
          + via-branch=... - Include the “branch” value of one of the
            “Via” headers in the request to the RTP proxy. Possible values
            are: “1” - use the first “Via” header; “2” - use the second
            “Via” header; “auto” - use the first “Via” header if this is a
            request, or the second one if this is a reply; “extra” - don't
            take the value from a header, but instead use the value of the
            “extra_id_pv” variable; “next” - use the branch ID generated
            by Kamailio for the next outgoing branch; “auto-next” - use
            “next” in requests and “1” in replies; “auto-extra” - use
            “extra” in requests and “1” in replies. This can be used to
            create one media session per branch on the RTP proxy. When
            sending a subsequent “delete” command to the RTP proxy, you
            can then stop just the session for a specific branch when
            passing the flag '1' or '2' in the “rtpengine_delete”, or stop
            all sessions for a call when not passing one of those two
            flags there. This is especially useful if you have serially
            forked call scenarios where the RTP proxy gets an “offer”
            command for a new branch, and then a “delete” command for the
            previous branch, which would otherwise delete the full call,
            breaking the subsequent “answer” for the new branch. This flag
            is only supported by the Sipwise rtpengine RTP proxy at the
            moment!
          + asymmetric - flags that UA from which message is received
            doesn't support symmetric RTP. Disables learning of endpoint
            addresses in the Sipwise rtpengine proxy.
          + no-redis-update - this flag can be used by Kamailio in order
            to tell rtpengine not to persist the call into Redis upon
            receiving offer/answer() control commands. If flag is not set,
            default action is rtpengine persists call to redis.
          + force-answer - force “answer”, that is, only rewrite SDP when
            corresponding session already exists in the RTP proxy. By
            default is on when the session is to be completed. This is
            only necessary when the offer was sent by rtpengine_offer(),
            and the answer is handled by rtpengine_manage().
          + direction=... - this option specifies a logical network
            interface and should be given exactly twice. It enables RTP
            bridging between different addresses or networks of the same
            family (e.g. IPv4 to IPv4). The first instance of the option
            specifies the interface that the originator of this message
            should be using, while the second instance specifies the
            interface that the target should be using. For example, if the
            SIP message was sent by an endpoint on a private network and
            will be sent to an endpoint on the public internet, you would
            use “direction=priv direction=pub” if those two logical
            network interfaces were called “priv” and “pub” in your RTP
            proxy's configuration respectively. The direction must only be
            specified in for initial SDP offer; answers or subsequent
            offers can omit this option.
          + internal, external - shorthand for “direction=internal” and
            “direction=external” respectively. Useful for brevity or as
            legacy option if the RTP proxy only supports two network
            interfaces instead of multiple, arbitrarily named ones.
          + address-family=... - instructs the RTP proxy that the
            recipient of this SDP body expects to see addresses of a
            particular family. Possible values are “IP4” and “IP6”. For
            example, if the SDP body contains IPv4 addresses but the
            recipient only speaks IPv6, you would use “address-family=IP6”
            to bridge between the two address families.
            Sipwise rtpengine remembers the address family preference of
            each party after it has seen an SDP body from them. This means
            that normally it is only necessary to explicitly specify the
            address family in the “offer”, but not in the “answer”.
            Note: Please note, that this will only work properly with
            non-dual-stack user-agents or with dual-stack clients
            according to RFC6157 (which suggest ICE for Dual-Stack
            implementations). This short-cut will not work properly with
            RFC4091 (ANAT) compatible clients, which suggests having
            different m-lines with different IP-protocols grouped
            together.
          + force - instructs the RTP proxy to ignore marks inserted by
            another RTP proxy in transit to indicate that the session
            already goes through another proxy. Allows creating a chain of
            proxies. Not supported and ignored by Sipwise rtpengine.
          + trust-address - flags that IP address in SDP should be
            trusted. Starting with rtpengine 3.8, this is the default
            behaviour. In older versions, without this flag the RTP proxy
            ignores the address in the SDP and uses source address of the
            SIP message as media address which is passed to the RTP proxy.
          + SIP-source-address - the opposite of trust-address. Restores
            the old default behaviour of ignoring endpoint addresses in
            the SDP body.
          + received-from=IP - Configure the SIP-source-address IP
            explicitly, which will be useful when two kamailio is cascaded
            where first kamailio is handling NAT and second kamailio
            RTPEngine.
          + replace-origin - flags that IP from the origin description
            (o=) should be also changed.
          + replace-session-connection - flags to change the session-level
            SDP connection (c=) IP if media description also includes
            connection information.
          + symmetric - flags that for the UA from which message is
            received, support symmetric RTP must be forced. Does nothing
            with the Sipwise rtpengine proxy as it is the default.
          + repacketize=NN - requests the RTP proxy to perform
            re-packetization of RTP traffic coming from the UA which has
            sent the current message to increase or decrease payload size
            per each RTP packet forwarded if possible. The NN is the
            target payload size in ms, for the most codecs its value
            should be in 10ms increments, however for some codecs the
            increment could differ (e.g. 30ms for GSM or 20ms for G.723).
            The RTP proxy would select the closest value supported by the
            codec. This feature could be used for significantly reducing
            bandwith overhead for low bitrate codecs, for example with
            G.729 going from 10ms to 100ms saves two thirds of the network
            bandwith. Not supported by Sipwise rtpengine.
          + ICE=... - controls the RTP proxy's behaviour regarding ICE
            attributes within the SDP body. Possible values are: “force” -
            discard any ICE attributes already present in the SDP body and
            then generate and insert new ICE data, leaving itself as the
            only ICE candidates; “force-relay” - discard any “relay” type
            ICE attributes already present in the SDP body and then
            generate and insert itself as the only ICE “relay” candidates;
            “remove” instructs the RTP proxy to discard any ICE attributes
            and not insert any new ones into the SDP. The default (if no
            “ICE=...” is given at all), new ICE data will only be
            generated if no ICE was present in the SDP originally;
            otherwise the RTP proxy will only insert itself as additional
            ICE candidate. Other SDP substitutions (c=, m=, etc) are
            unaffected by this flag.
          + RTP, SRTP, DTLS, AVP, AVPF - These flags control the RTP
            transport protocol that should be used towards the recipient
            of the SDP. If none of them are specified, the protocol given
            in the SDP is left untouched. Otherwise, the “SRTP” flag
            indicates that SRTP should be used, while “RTP” indicates that
            both SRTP and AVPF should not be used. “AVPF” indicates that
            the advanced RTCP profile with feedback messages should be
            used, and “AVP” indicates that the regular RTCP profile should
            be used. See also the next set of flags below.
          + RTP/AVP, RTP/SAVP, UDP/TLS/RTP/SAVP, RTP/AVPF, RTP/SAVPF,
            UDP/TLS/RTP/SAVPF - these serve as an alternative, more
            explicit way to select between the different RTP protocols and
            profiles supported by the RTP proxy. For example, giving the
            flag “RTP/SAVPF” has the same effect as giving the two flags
            “SRTP AVPF”.
          + to-tag - force inclusion of the “To” tag. Normally, the “To”
            tag is always included when present, except for “delete”
            messages. Including the “To” tag in a “delete” messages allows
            you to be more selective about which dialogues within a call
            are being torn down.
          + to-tag=... - use the specified string as “To” tag instead of
            the actual “To” tag from the SIP message, and force inclusion
            of the tag in the message as per above.
          + from-tag=... - use the specified string as “From” tag instead
            of the actual “From” tag from the SIP message.
          + call-id=... - use the specified string as “Call-ID” instead of
            the actual “Call-ID” from the SIP message.
          + rtcp-mux-demux - if rtcp-mux (RFC 5761) was offered, make the
            RTP proxy accept the offer, but not offer it to the recipient
            of this message.
          + rtcp-mux-reject - if rtcp-mux was offered, make the RTP proxy
            reject the offer, but still offer it to the recipient. Can be
            combined with “rtcp-mux-offer” to always offer it.
          + rtcp-mux-offer - make the RTP proxy offer rtcp-mux to the
            recipient of this message, regardless of whether it was
            offered originally or not.
          + rtcp-mux-accept - if rtcp-mux was offered, make the RTP proxy
            accept the offer and also offer it to the recipient of this
            message. Can be combined with “rtcp-mux-offer” to always offer
            it.
          + media-address=... - force a particular media address to be
            used in the SDP body. Address family is detected
            automatically.
          + TOS=... - change the IP TOS value for all outgoing RTP packets
            within the entire call in both directions. Only honoured in an
            “offer”, ignored for an “answer”. Valid values are 0 through
            255, given in decimal. If this option is not specified, the
            TOS value will revert to the default TOS (normally 184). A
            value of -1 may be used to leave the currently used TOS
            unchanged.
          + delete-delay=... - override the default delay (in seconds)
            before a call is actually deleted from memory. Can be set to
            zero to effectuate immediate deletion. This option only makes
            sense for delete operations.
          + strict-source - instructs the RTP proxy to check the source
            addresses of all incoming RTP packets and drop the packets if
            the address doesn't match.
          + media-handover - the antithesis of strict-source. Instructs
            the RTP proxy not only to accept mismatching RTP source
            addresses (as it normally would), but also to accept them as
            the new endpoint address of the opposite media flow. Not
            recommended as it allows media streams to be hijacked by an
            attacker.
          + DTLS=... - influence the behaviour of DTLS-SRTP. Possible
            values are “no” or “off” to suppress offering or accepting
            DTLS-SRTP, and “passive” to prefer participating in DTLS-SRTP
            in a passive role.
          + SDES-off - don't offer SDES when it normally would. In an SRTP
            context, this leaves DTLS-SRTP as the only other option.
          + SDES-unencrypted_srtp, SDES-unencrypted_srtcp,
            SDES-unauthenticated_srtp - these directly reflect the SDES
            session parameters from RFC 4568 and will make the RTP proxy
            offer these parameters when offering SDES.
          + SDES-encrypted_srtp, SDES-encrypted_srtcp,
            SDES-authenticated_srtp - the opposites of the flags above.
            Useful if accepting these parameters is not desired and they
            should be rejected instead.
          + SDES-nonew - don't add any new crypto suites into the offer.
            This means, offered SDES crypto suites will be accepted,
            meanwhile no new is going to be generated by RTPEngine. It
            takes precedence over the `SDES-no` and `SDES-only` flags, if
            used in combination.
          + SDES-pad - RFC 4568 (section 6.1) is somewhat ambiguous
            regarding the base64 encoding format of `a=crypto` parameters
            added to an SDP body. The default interpretation is that
            trailing `=` characters used for padding should be omitted.
            With this flag set, these padding characters will be left in
            place.
          + unidirectional - allows kernelization of one-way streams in
            the Sipwise rtpengine proxy. This is especially useful when
            the first call leg is handled by some rtpengine machine while
            the second call leg is handled by other rtpengine machine.
          + record-call=on - instructs RTPEngine to record the session.
            Use it in rtpengine_offer() to start recording immediately and
            save the call metadata, as alternative to start_recording().
          + metadata - a generic metadata string. The metadata will be
            used when recording calls to provide custom additional
            information. More details about this are found in the
            rtpengine README.
          + codec-transcode=... - allows codecs to be added to the list of
            offered codecs even if they were not present in the original
            list of codecs. In this case, the transcoding engine will be
            engaged. Only codecs that are supported for both decoding and
            encoding can be added in this manner. More details about this
            are found in the rtpengine README.
          + codec-set=... - set codec options (bitrate etc) for codecs
            that are implicitly accepted for transcoding from the offering
            side.
          + codec-strip=... - strips given codec from sdp
          + codec-offer=... - offer given codec from sdp. More details
            about this are found in the rtpengine README.
          + codec-except=... - same as codec-offer but preserves original
            order
          + codec-mask=... - similar to strip except that codecs listed
            here will still be accepted and used for transcoding on the
            offering side. Useful only in combination with
            codec-transcode. all keyword can be used to mask all offered
            codecs
          + codec-accept=... - similar to `mask` and `consume` but doesn't
            remove the codec from the list of offered codecs. This means
            that a codec listed under `accept` will still be offered to
            the remote peer, but if the remote peer rejects it, it will
            still be accepted towards the original offerer and then used
            for transcoding. It is a more selective version of what the
            `always transcode` flag does.
          + codec-consume=... - identical to mask but enables the
            transcoding engine even if no other transcoding related
            options are given.
          + T.38=decode - if the offered SDP contains a media section
            advertising T.38 over UDPTL, translate it to a regular audio
            media section over RTP. By default, PCMU and PCMA will be used
            as audio codecs, but that can be overridden using the codec
            options described above. Other transport protocols (e.g. SRTP)
            can also be selected in the same way. If the offered SDP does
            not contain a T.38 section, then this flag has no effect.
          + T.38=force - any audio media section (over RTP) in the offered
            SDP will be translated into a T.38 section over UDPTL.
          + T.38=stop - stops a previously established T.38 to audio
            gateway and reverts the session back to media passthrough.
            This is useful when handling a rejected T.38 offer.
          + label=... - adds a label to a current stream, that later can
            be used to get call quality stats, see “mos_A_label_pv” and
            “mos_B_label_pv” parameters.
          + debug - enables debug logging (rtpengine log level 7) for this
            call only. rtpengine will log everything related to that call
            after parsing the flags. Useful in debugging scenarios.
       Check also the documentation of RTPEngine, these flags are
       documented there as well: https://github.com/sipwise/rtpengine.
     * via-branch - provide the via-branch taken from one of SIP message
       Via headers.
       The “via-branch” parameter helps to match NG command (offer,
       answer, delete etc.) to particular monologue. It does the same job
       as the “via-branch” option flag, but it also enables alternative
       parsing behavior, when option flags are passed to rtpengine using
       bencode string format and is then parsed there. The benefit of the
       second approach is that any new flags supported by rtpengine will
       automatically be supported without having to worry about support in
       the control module. Regardless whether the flags parsing is done by
       the module or daemon, a functional behavior remains the same and
       has no difference in terms of SDP processing. Possible values are
       the same as for the “via-branch” option flag. If the newer approach
       is to be applied, but no “via-branch” is meant to be added for
       identfication, then “none” can be given instead. This parameter can
       be applied for the rtpengine versions equal or later than mr12.4.

   This function can be used from ANY_ROUTE.

   Example 1.91. rtpengine_offer usage
request_route {
...
    if (is_method("INVITE")) {
        if (has_body("application/sdp")) {
            if (rtpengine_offer())
                t_on_reply("1");
        } else {
            t_on_reply("2");
        }
    }
    if (is_method("ACK") && has_body("application/sdp"))
        rtpengine_answer();
...
}

onreply_route[1]
{
...
    if (has_body("application/sdp"))
        rtpengine_answer();
...
}

onreply_route[2]
{
...
    if (has_body("application/sdp"))
        rtpengine_offer();
...
}
...
if (has_body("application/sdp")) {
    if (rtpengine_offer("codec-mask=all codec-transcode=PCMU codec-transcode=PCM
A"))
        t_on_reply("1");
}

...

   Example 1.92. rtpengine_offer usage to force transcoding from opus to
   PCMU
request_route {
...
    if (is_method("INVITE")) {
        if (has_body("application/sdp")) {
            if (rtpengine_offer("codec-mask=opus codec-accept=opus codec-strip=P
CMU codec-transcode=PCMU"))
                t_on_reply("1");
        }
    }
...
}

onreply_route[1]
{
...
    if (has_body("application/sdp"))
        rtpengine_answer("codec-strip=PCMU codec-strip=PCMA");
...
}
...

   Example 1.93. rtpengine_offer usage of via-branch parameter
request_route {
...
    if (is_method("INVITE")) {
        if (has_body("application/sdp")) {
            if (rtpengine_offer("replace-origin replace-session-connection stric
t-source label=callee OSRTP-accept transport-protocol=RTP/AVP address-family=IP4
", "auto-next"))
                t_on_reply("1");
        }
    }
...
}

15.3.  rtpengine_answer([flags][,via-branch])

   Rewrites SDP body to ensure that media is passed through an RTP proxy.
   To be invoked on 200 OK for the cases the SDP bodies are in INVITE and
   200 OK and on ACK when SDP bodies are in 200 OK and ACK.

   See rtpengine_offer() function description above for the meaning of the
   parameters.

   This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE,
   FAILURE_ROUTE, BRANCH_ROUTE.

   Example 1.94. rtpengine_answer usage

   See rtpengine_offer() function example above for example.

15.4.  rtpengine_info([flags][,via-branch])

   Send an updated offer to rtpengine. This is meant to be used when
   processing Trickle ICE SDP Fragments that are carried in SIP INFO
   messages and are proxied to endpoints that do not support ICE. With a
   matching content type, the SDP fragment is used to update rtpengine's
   list of ICE candidates. No new SDP is returned and so the SIP INFO
   message should be consumed after calling this function.

   While this function supports the same flags as “rtpengine_offer” et al,
   it is not normally necessary to provide any.

   This function can be used from ANY_ROUTE.

   Example 1.95. rtpengine_info usage
...
rtpengine_info();
...

15.5.  rtpengine_delete([flags][,via-branch])

   Tears down the RTP proxy session for the current call. This populates
   the statistics pseudovariables (such “mos_min_pv” etc).

   See rtpengine_offer() function description above for the meaning of the
   parameters. Note that not all flags make sense for a “delete”.

   This function can be used from ANY_ROUTE.

   Example 1.96. rtpengine_delete usage
...
rtpengine_delete();
...

15.6.  rtpengine_destroy([flags][,via-branch])

   Same as rtpengine_delete().

   Example 1.97. rtpengine_destroy usage
...
rtpengine_destroy();
...

15.7.  rtpengine_query([flags][,via-branch])

   Queries the RTP proxy about the current status and statistics of a
   running call. This populates the statistics pseudovariables (such
   “mos_min_pv” etc).

   See rtpengine_offer() function description above for the meaning of the
   parameters. Note that not all flags make sense for a “query”.

   This function can be used from ANY_ROUTE.

   Example 1.98. rtpengine_query usage
...
rtpengine_query();
...

15.8.  rtpengine_query_v(fmt, var)

   Queries the RTP proxy about the current status and statistics of a
   running call, converts the response to JSON according to fmt and sets
   the variable var with the result.

   The fmt parameter can be 'j' for compacted JSON and 'jp' for
   pretty-formatted JSON.

   The var parameter has to be the name of a writable variable.

   This function can be used from ANY_ROUTE.

   Example 1.99. rtpengine_query_v usage
...
if(rtpengine_query_v("j", "$var(rdata)")) {
    xinfo("rtpengine query response: $var(rdata)\n");
}
...

15.9.  rtpengine_connect([flags][,via-branch])

   Connects the media of two call parties directly without the need for a
   full offer/answer exchange. The media will be connected in the same way
   as it would through an offer/answer exchange. Transcoding will
   automatically be engaged if needed.

   See rtpengine_query() function description above for the meaning of the
   parameters. The function requires call-id, from-tag, and to-tag to
   identify the two call parties to connect. Optionally, to-call-id can be
   specified in flags to connect parties from different calls (different
   call IDs).

   This function can be used from ANY_ROUTE.

   Example 1.100. rtpengine_connect usage
...
# Connect two parties from the same call (using tags from current SIP message)
rtpengine_connect();

# Connect two parties from different calls, specifying all parameters
rtpengine_connect("call-id=abc123def456@192.168.1.100 from-tag=a1b2c3d4 to-tag=e
5f6g7h8 to-call-id=xyz789ghi012@192.168.1.200");
...

15.10.  rtpengine_manage([flags][,via-branch])

   Manage the RTPEngine session - it combines the functionality of
   rtpengine_offer(), rtpengine_answer() and rtpengine_delete(), detecting
   internally based on message type and method which one to execute.

   It can take the same parameters as rtpengine_offer(). The flags
   parameter to rtpengine_manage() can be a configuration variable
   containing the flags as a string.

   Functionality:
     * If INVITE with SDP, then do rtpengine_offer()
     * If INVITE with SDP, when the tm module is loaded, mark transaction
       with internal flag FL_SDP_BODY to know that the 1xx and 2xx are for
       rtpengine_answer()
     * If ACK with SDP, then do rtpengine_answer()
     * If BYE or CANCEL, or called within a FAILURE_ROUTE[], then call
       rtpengine_delete(). Be careful with calling this function after
       resuming a suspended transaction (e.g., after t_continue()),
       because the context of executed route is FAILURE ROUTE (in other
       words, rtpengine_manage() in the route block of t_continue() does
       the same as in failure_route; use a branch route to engage
       rtpengine for a forwarded branch after resuming the transaction).
     * It does nothing if used inside event_route[tm:branch-failure:...]
     * If reply to INVITE with code >= 300 do rtpengine_delete()
     * If reply with SDP to INVITE having code 1xx and 2xx, then do
       rtpengine_answer() if the request had SDP or tm is not loaded,
       otherwise do rtpengine_offer()

   This function can be used from ANY_ROUTE.

   Example 1.101. rtpengine_manage usage
...
rtpengine_manage();
...

15.11.
rtpengine_subscribe_request(flags,sdp_avp,to_tag_avp,stream_xavp[,via-branch]
)

   Generates SDP body for forking the current RTP stream and stores it in
   the xavp specified “sdp_avp” AVP. The new call leg will be identified
   by the generated (or specified) to tag that will be put in the
   “to_tag_avp” AVP. on INVITE for the cases the SDP bodies are in INVITE
   and 200 OK and on 200 OK when SDP bodies are in 200 OK and ACK.

   The function will return true on success and false (-1) on various
   failures, like using rtpengine_subscribe_request() before an rtpengine
   session was established.

   Meaning of the parameters is as follows:
     * flags - flags to turn on some features.
       The “flags” string is a list of space-separated items. Each item is
       either an individual token, or a token in “key=value” format. The
       possible tokens are described below. This offer SDP can be
       manipulated with the same flags as used in rtpengine_offer
       additionally, the following extra flags can be used
          + from-tags=... - Specifies which participants in the call
            should have their media forked. This value can be repeated
            multiple times to specify multiple participants. To specify
            all participants, use “all” as an alternative.
          + all - forks the media stream for all participants in the call.
            Use instead of “from-tags=...”
          + siprec - indicates that the SDP should be in SIPREC format.
            The flag “all” should also be used in this case.
       Check also the documentation of RTPEngine, these flags are
       documented there as well: https://github.com/sipwise/rtpengine.
     * sdp_avp - the name of the AVP where the generated SDP will be
       stored.
       The “sdp_avp” parameter is mandatory and must be a writable AVP.
       The AVP will be set to the generated SDP body, which can then be
       used in a subsequent “t_uac_send()” call to send the offer to the
       new participant.
     * to_tag_avp - the name of the AVP where to store the to tag of the
       new call leg.
       The “to_tag_avp” parameter is mandatory and must be a writable AVP.
       The to tag will either be auto generated or taken from the value
       specified in the “to-tag” flag.
     * stream_xavp - XAVP to store the stream information.
       The “stream_xavp” parameter is mandatory and must be a writable
       XAVP. The XAVP will be a stack, one for each participant. Each
       stack element will have a key “tag” to identify the participant,
       and a key “label” which is an array of labels, (each stream in the
       RTP will have a label attribute in the generated SDP).
     * via-branch - provide the via-branch taken from one of SIP message
       Via headers.
       The “via-branch” parameter helps to match NG command (offer,
       answer, delete etc.) to particular monologue. It does the same job
       as the “via-branch” option flag, but it also enables alternative
       parsing behavior, when option flags are passed to rtpengine using
       bencode string format and is then parsed there. The benefit of the
       second approach is that any new flags supported by rtpengine will
       automatically be supported without having to worry about support in
       the control module. Regardless whether the flags parsing is done by
       the module or daemon, a functional behavior remains the same and
       has no difference in terms of SDP processing. Possible values are
       the same as for the “via-branch” option flag. If the newer approach
       is to be applied, but no “via-branch” is meant to be added for
       identfication, then “none” can be given instead. This parameter can
       be applied for the rtpengine versions equal or later than mr12.4.
     * via-branch - provide the via-branch taken from one of SIP message
       Via headers.
       The “via-branch” parameter helps to match NG command (offer,
       answer, delete etc.) to particular monologue. It does the same job
       as the “via-branch” option flag, but it also enables alternative
       parsing behavior, when option flags are passed to rtpengine using
       bencode string format and is then parsed there. The benefit of the
       second approach is that any new flags supported by rtpengine will
       automatically be supported without having to worry about support in
       the control module. Regardless whether the flags parsing is done by
       the module or daemon, a functional behavior remains the same and
       has no difference in terms of SDP processing. Possible values are
       the same as for the “via-branch” option flag. If the newer approach
       is to be applied, but no “via-branch” is meant to be added for
       identfication, then “none” can be given instead. This parameter can
       be applied for the rtpengine versions equal or later than mr12.4.

   This function can be used from ANY_ROUTE.

   Example 1.102. rtpengine_subscribe_request usage
request_route {
...
    if (is_method("INVITE")) {
        if (has_body("application/sdp")) {
            if (rtpengine_offer())
                t_on_reply("1");
        }
    }
...
}

onreply_route[1]
{
...
    if (has_body("application/sdp")) {
        rtpengine_answer();
        rtpengine_subscribe_request("all siprec", "$avp(siprec_offer)",
                                    "$avp(siprec_to_tag)", "siprec_streams");
        xinfo("SIPREC participant $xavp(siprec_streams[0]=>tag) with label $xavp
(siprec_streams[0]=>label[0])\n");
        xinfo("SIPREC participant $xavp(siprec_streams[1]=>tag) with label $xavp
(siprec_streams[0]=>label[0])\n");
        # use the above stream information to build the siprec xml metadata, wil
l just send SDP in this example
        $dlg_var(orig_to_tag) = $tt;
        $dlg_var(siprec_contact) = "sip:uac@" + $Ri;
        $dlg_var(siprec_to_tag) = $avp(siprec_to_tag);
        t_uac_send("INVITE" ,"sip:siprec@siprec_server.example.com",
                   "siprec_server.example.com", "",
                   "To: <$tu>\r\n" +
                   "From: <$fu>\r\n" +
                   "Contact: <$dlg_var(siprec_contact)>\r\n" +
                   "Content-Type: application/sdp\r\n",
                   $avp(siprec_offer));
        }
...
}

event_route [tm:local-request] {
    if (is_method("INVITE")) {
        # save information from the original dialog to the new invite transactio
n
        $avp(orig_callid) = $dlg(callid);
        $avp(orig_from_tag) = $dlg(from_tag);
        $avp(orig_to_tag) = $dlg_var(orig_to_tag);
        $avp(siprec_to_tag) = $dlg_var(siprec_to_tag);
        $avp(siprec_contact) = $dlg_var(siprec_contact);
        t_on_reply("2");
    }
    if (is_method("ACK")) {
        # save the route set in the original dialog
        dlg_get($avp(orig_callid), $avp(orig_from_tag), $avp(orig_to_tag));
        $dlg_var(siprec_cseq) = $cs;
        $dlg_var(siprec_to_hdr) = $hdr(To);
        $dlg_var(siprec_from_hdr) = $hdr(From);
        append_hf("Contact: <$dlg_var(siprec_contact)>\r\n");

        # the same dialog information can be used to send the BYE with t_uac_sen
d
    }
}

onreply_route[2] {
    if (has_body("application/sdp")) {
       rtpengine_subscribe_answer("from-tag=$avp(orig_from_tag) to-tag=$avp(sipr
ec_to_tag) call-id="$avp(orig_callid)");
    }
}
...

15.12.  rtpengine_subscribe_answer([flags][,via-branch])

   Sends the SDP answer from the recording server to the rtpengine

   This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE,
   FAILURE_ROUTE, BRANCH_ROUTE.

   Meaning of the parameters is as follows:
     * flags - flags to turn on some features.
       The “flags” string is a list of space-separated items. Each item is
       either an individual token, or a token in “key=value” format. The
       possible tokens are described below. This offer SDP can be
       manipulated with the same flags as used in rtpengine_offer
       additionally, the following extra flags can be used
          + to-tag=... - value of the to tag returned by
            “rtpengine_subscribe_request”
          + from-tag=... - value of the from tag of the original call.
          + call-id=... - value of the call id of the original call.

   Example 1.103. rtpengine_subscribe_answer usage

   See rtpengine_subscribe_request() function example above for example.

15.13.  rtpengine_unsubscribe([flags][,via-branch])

   Sends the SDP answer from the recording server to the rtpengine

   This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE,
   FAILURE_ROUTE, BRANCH_ROUTE.

   Meaning of the parameters is as follows:
     * flags - flags to turn on some features.
       The “flags” string is a list of space-separated items. Each item is
       either an individual token, or a token in “key=value” format. The
       possible tokens are described below. This offer SDP can be
       manipulated with the same flags as used in rtpengine_offer
       additionally, the following extra flags can be used
          + to-tag=... - value of the to tag returned by
            “rtpengine_subscribe_request”
          + from-tag=... - value of the from tag of the original call.
          + call-id=... - value of the call id of the original call.

   Example 1.104. rtpengine_unsubscribe usage

event_route [dialog:end] {
    # call over, stop recording
    rtpengine_unsubscribe("from-tag=$avp(orig_from_tag) to-tag=$avp(siprec_to_ta
g) call-id="$avp(orig_callid)");
    $var(new_cseq) = $dlg_var(siprec_cseq) + 1;
    t_uac_send("BYE", "sip:siprec@siprec_server.example.com",
               "siprec_server.example.com", "",
               "To: <$dlg_var(siprec_to_hdr)>\r\n" +
               "From: <$dlg_var(siprec_from_hdr)>\r\n" +
               "Call-ID: $avp(siprec_callid)\r\n" +
               "CSeq: $var(new_cseq) BYE\r\n" +
               "Contact: $lt;$dlg_var(siprec_contact)>\r\n");
}
...

15.14.  start_recording([flags])

   This function will send a signal to the RTP relay to record the RTP
   stream flowing through it. See also the option “record-call=on” for
   rtpengine_manage()/rtpengine_offer(), which offers an alternative for
   call recording, saving also call metadata from SDP.

   It can take the same parameters as rtpengine_manage(). The flags
   parameter to start_recording can be a configuration variable containing
   the flags as a string. The call-id flag can be used to start recording
   for a different call.

   This function can be used from REQUEST_ROUTE and ONREPLY_ROUTE.

   Example 1.105. start_recording usage
...
start_recording();
...

15.15.  stop_recording([flags])

   This function will send a signal to the RTP relay to stop recording the
   RTP stream flowing through it. See also the option “record-call=off”
   for rtpengine_manage()/rtpengine_offer(), which offers an alternative
   for call recording.

   It can take the same parameters as rtpengine_manage(). The flags
   parameter to start_recording can be a configuration variable containing
   the flags as a string. The call-id flag can be used to stop recording
   for a different call.

   This function can be used from REQUEST_ROUTE and ONREPLY_ROUTE.

   Example 1.106. stop_recording usage
...
stop_recording();
...

15.16.  block_dtmf([flags])

   This function will instruct the RTP proxy to start blocking DTMF event
   packets (RFC 4733). DTMF events will still be processed by the RTP
   proxy, but they won't be forwarded to the receiving peer.

   The call-id flag can be used to block DTMF for a different call.

   Without any flags given, DTMF events will be blocked for the entire
   call. It's possible to block DTMF directionally only for individual
   participants. If the “directional” flag is given, DTMF events will be
   blocked for the UA with the currently matching “From” tag. Events can
   be blocked for a different UA either by specifying an alternative
   “from-tag=...”, or by matching UAs against the media address they
   advertised in the SDP using the “address=...” flag (which can contain
   either an IPv4 or IPv6 address).

   This function can be used from REQUEST_ROUTE and ONREPLY_ROUTE.

   Example 1.107. block_dtmf usage
...
block_dtmf();
block_dtmf("directional");
block_dtmf("address=192.168.42.42");
...

15.17.  unblock_dtmf([flags])

   Reverses the effects of a previously issued block_dtmf call. See above
   for a description of which flags can be used.

   If DTMF events were previously blocked for individual UAs, then
   unblocking DTMF events for the entire call (i.e. no flags given) will
   not remove these blocks. The flag “all” can be used to achieve this.

   Example 1.108. unblock_dtmf usage
...
unblock_dtmf();
unblock_dtmf("all");
...

15.18.  block_media([flags])

   Analogous to “block_dtmf”, but blocks media RTP packets instead of DTMF
   events. When media is blocked, DTMF events still pass through the RTP
   proxy.

   See “block_dtmf” for a description of the flags that can be used.

   Example 1.109. block_media usage
...
block_media();
block_media("directional");
block_media("address=192.168.42.42");
...

15.19.  unblock_media([flags])

   Analogous to “unblock_dtmf”, but applies to media RTP packets instead
   of DTMF events.

   See “unblock_dtmf” for a description of the flags that can be used.

   Example 1.110. unblock_media usage
...
unblock_media();
unblock_media("all");
...

15.20.  silence_media([flags])

   Identical to “block_media” except that media RTP packets are not simply
   blocked, but instead have their audio payload replaced by silence
   audio. This is only supported for certain trivial audio codecs (e.g.
   G.711, G.722).

   See “block_dtmf” for a description of the flags that can be used.

   Example 1.111. silence_media usage
...
silence_media();
silence_media("directional");
silence_media("address=192.168.42.42");
...

15.21.  unsilence_media([flags])

   Identical to “unblock_media” except that it's the counterpart to
   “silence_media”.

   See “unblock_dtmf” for a description of the flags that can be used.

   Example 1.112. unsilence_media usage
...
unsilence_media();
unsilence_media("all");
...

15.22.  start_forwarding([flags])

   Controls the PCM forwarding feature of the recording daemon. Unlike the
   recording feature, PCM forwarding can be done directionally for
   individual call participants only, therefore this command takes the
   same flags as the media/DTMF blocking commands above.

   See “block_dtmf” for a description of the flags that can be used.

   Example 1.113. start_forwarding usage
...
start_forwarding();
start_forwarding("directional");
start_forwarding("address=192.168.42.42");
...

15.23.  stop_forwarding([flags])

   Analogous to “unblock_dtmf”, but controls the PCM forwarding feature
   instead of DTMF blocking.

   See “unblock_dtmf” for a description of the flags that can be used.

   Example 1.114. stop_forwarding usage
...
stop_forwarding();
stop_forwarding("all");
...

15.24.  play_media([flags])

   Instructs rtpengine to play a prerecorded announcement to the selected
   call participant, either from a local file or from a file stored in a
   database. The participant must be selected using the same flags as are
   described under the “block_dtmf” function. If none of these flags are
   given, then the “From” tag from the current SIP message context is
   used.

   If successful, the “media_duration” pseudovariable is filled in with
   the duration of the media being played, expressed in milliseconds. If
   the length of the media could not be determined, it's set to -1.

   Example 1.115. play_media usage
...
play_media("file=/use/share/media/hello.wav");
play_media("from-tag=tfugklbildfydrtuykgfv db-id=12345");
...

15.25.  stop_media([flags])

   Stops the playback of media previously started by “play_media”. Media
   playback is automatically stopped when the end of the media file is
   reached, so this function is only useful to prematurely stop playback.

   Example 1.116. stop_media usage
...
stop_media();
stop_media("from-tag=5yqaeriguhxcikxj");
...

15.26.  play_dtmf([flags])

   Injects a DTMF event into the media stream. Depending on which codecs
   were negotiated, this either injects an RFC 2833/4733 DTMF event, or an
   in-band PCM DTMF tone into the audio stream. The flag “inject DTMF”
   must have been present in both offer and answer messages when the call
   was established, which forces all audio to go through rtpengine's
   transcoding engine.

   Usage is similar to “play_media” with the following exceptions. The
   selected party is not the party that will receive the DTMF event, but
   rather the party which is generating the event. This is to support DTMF
   events that are carried in SIP INFO messages. Instead of specifying a
   media file, a DTMF event code must be specified, as well as optionally
   a duration and the volume. The “code” can be a number 0 through 15, or
   a DTMF digit (0-9, A-D, *, #). The “duration” is specified in
   milliseconds and defaults to 250, within a range of 100-5000. The
   “volume” is specified in absolute decibels, with a default of -8 db.

   Multiple consecutive DTMF events can be queued up by calling this
   function multiple times consecutively. RTPengine will play out the DTMF
   events in sequence, separated by a default pause of 100 ms. An
   alternative pause length can be given through the “pause” option,
   between 100 and 5000 ms.

   Example 1.117. play_dtmf usage
...
play_dtmf("from-tag=5yqaeriguhxcikxj code=#");
play_dtmf("code=1 volume=5 duration=300 pause=150");
...

16. Exported Pseudo Variables

   16.1. $rtpestat
   16.2. $rtpstat

16.1. $rtpestat

   Returns the RTP statistics from the RTP relay. The RTP statistics from
   the RTP relay are provided as a string and it does contain several
   packet counters. The statistics must be retrieved before the session is
   deleted (before rtpengine_delete()).

   Example 1.118. $rtpestat Usage
...
append_hf("X-RTP-Statistics: $rtpestat\r\n");
...
# $rtpestat = RTP: 54846 bytes, 1447 packets, 0 errors; RTCP: 336 bytes, 3 packe
ts, 0 errors
...

16.2. $rtpstat

   Same as $rtpestat.

17. RPC Commands

   17.1. rtpengine.reload
   17.2. rtpengine.enable proxy_url/all 0/1
   17.3. rtpengine.show proxy_url/all
   17.4. rtpengine.ping proxy_url/all
   17.5. rtpengine.get_hash_total

17.1. rtpengine.reload

   Reloads the database node table content if configured. Returns specific
   message related to success, failure and no db_url configured.

   NOTE: The current behaviour updates the nodes state or creates new ones
   or hides old ones, based on the database content. If allow_op modparam
   is enabled, the sessions are still allowed to finish for the hidden old
   nodes.

   The execution of this command is limited to 10 seconds intervals.

   Example 1.119.  rtpengine.reload usage
...
$ kamctl rpc rtpengine.reload
...

17.2. rtpengine.enable proxy_url/all 0/1

   Enables a RTP proxy if the second parameter value is greater than 0.
   Disables it if a zero value is given. The first parameter is either a
   specific RTP proxy url (exactly as defined in the config file) or the
   keyword all. The second parameter value must be a number in decimal.

   When try to enable the RTP proxy, an application ping command is sent
   to it. If it fails, the proxy is not enabled. Displays success or fail
   when try to enable/disable.

   NOTE: If a RTP proxy is defined multiple times (in the same or
   different sets), all of its instances will be enabled/disabled.

   NOTE: If a RTP proxy is in the disabled permanent state and one tries
   to enable it, even if the ping fails, it is moved to a disabled
   temporary state and a recheck_ticks are given to it. While the
   recheck_ticks are grater than 0, the proxy is considered disabled
   temporary, and it is not taken into consideration for sending data.
   When the recheck_ticks are 0, the proxy is retested when trying to send
   data (not automatically retested), and data can be sent to it on
   success.

   NOTE: If you specify an IPv6 RTP, the proxy url must be prefixed with
   :: to escape the :: from the IPv6 address. See the example below.

   Example 1.120.  rtpengine.enable usage
...
$ kamctl rpc rtpengine.enable udp:192.168.2.133:8081 0
$ kamctl rpc rtpengine.enable ::udp6:fe80::9a90:96ff:fea8:fd99:9999 1
$ kamctl rpc rtpengine.enable all 1
...

17.3. rtpengine.show proxy_url/all

   Displays all the RTP proxies and their information: set and status
   (disabled or not, weight and recheck_ticks). If a RTP proxy has been
   disabled by nh_enable_rtpp mi command a "(permanent)" quote will appear
   when printing the disabled status. This is to differentiate from a
   temporary disable due to the proxy being not found responsive by
   kamailio. In addition, when disabled permanent, recheck_ticks have no
   meaning and "N\A" is printed instead of the value.

   It takes either a specific RTP proxy url (exactly as defined in the
   config file) or the keyword all as a parameter.

   NOTE: When specify the IPv6 RTP proxy url one must prefix it with :: to
   escape the :: from the IPv6 address. See the example below.

   Example 1.121.  rtpengine.show usage
...
$ kamctl rpc rtpengine.show udp:192.168.2.133:8081
$ kamctl rpc rtpengine.show ::udp6:fe80::9a90:96ff:fea8:fd99:9999
$ kamctl rpc rtpengine.show all
...

17.4. rtpengine.ping proxy_url/all

   Sends an application ping command to the RTP proxy. If the proxy does
   not respond, it will be disabled, but not permanent. If the proxy
   responds, no action is taken. Displays the ping result, i.e. success or
   fail when try to ping.

   It takes either a specific RTP proxy url (exactly as defined in the
   config file) or the keyword all as a parameter.

   NOTE: When specify the IPv6 RTP proxy url one must prefix it with :: to
   escape the :: from the IPv6 address. See the example below.

   Example 1.122.  rtpengine.ping usage
...
$ kamctl rpc rtpengine.ping udp:192.168.2.133:8081
$ kamctl rpc rtpengine.ping ::udp6:fe80::9a90:96ff:fea8:fd99:9999
$ kamctl rpc rtpengine.ping all
...

17.5. rtpengine.get_hash_total

   Print the total number of hash entries in the hash table at a given
   moment.

   Example 1.123.  rtpengine.get_hash_total usage
...
$ kamctl rpc rtpengine.get_hash_total
...

18. Event routes

   18.1. rtpengine:dtmf-event

18.1.  rtpengine:dtmf-event

   When defined, the module calls event_route[rtpengine:dtmf-event] when a
   DTMF is received.
...
event_route[rtpengine:dtmf-event] {
    xlog("L_INFO", "callid: $avp(dtmf_event_callid)\n");
    xlog("L_INFO", "source_tag: $avp(dtmf_event_source_tag)\n");
    xlog("L_INFO", "timestamp: $avp(dtmf_event_timestamp)\n");
    xlog("L_INFO", "dtmf: $avp(dtmf_event)\n");
}
...

Chapter 2. Frequently Asked Questions

   2.1. How do I migrate from “rtpproxy” or “rtpproxy-ng” to “rtpengine”?
   2.2. Where can I find more about Kamailio?
   2.3. Where can I post a question about this module?
   2.4. How can I report a bug?

   2.1.

   How do I migrate from “rtpproxy” or “rtpproxy-ng” to “rtpengine”?

   For the most part, only the names of the functions have changed, with
   “rtpproxy” in each name replaced with “rtpengine”. For example,
   “rtpproxy_manage()” has become “rtpengine_manage()”. A few name
   duplications have also been resolved, for example there is now a single
   “rtpengine_delete()” instead of “unforce_rtp_proxy()” and the identical
   “rtpproxy_destroy()”.

   The largest difference to the old module is how flags are passed to
   “rtpengine_offer()”, “rtpengine_answer()”, “rtpengine_manage()” and
   “rtpengine_delete()”. Instead of having a string of single-letter
   flags, they now take a string of space-separated items, with each item
   being either a single token (word) or a “key=value” pair.

   For example, if you had a call “rtpproxy_offer("FRWOC+PS");”, this
   would then become:
rtpengine_offer("force trust-address symmetric replace-origin replace-session-co
nnection ICE=force RTP/SAVPF");

   Finally, if you were using the second parameter (explicit media
   address) to any of these functions, this has been replaced by the
   “media-address=...” option within the first string of flags.

   2.2.

   Where can I find more about Kamailio?

   Take a look at https://www.kamailio.org/.

   2.3.

   Where can I post a question about this module?

   First at all check if your question was already answered on one of our
   mailing lists:
     * User Mailing List -
       https://lists.kamailio.org/mailman3/postorius/lists/sr-users.lists.
       kamailio.org/
     * Developer Mailing List -
       https://lists.kamailio.org/mailman3/postorius/lists/sr-dev.lists.ka
       mailio.org/

   E-mails regarding any stable Kamailio release should be sent to
   <sr-users@lists.kamailio.org> and e-mails regarding development
   versions should be sent to <sr-dev@lists.kamailio.org>.

   2.4.

   How can I report a bug?

   Please follow the guidelines provided at:
   https://github.com/kamailio/kamailio/issues.
