|
|
@@ -1,4 +1,4 @@
|
|
|
-rtpproxy-ng Module
|
|
|
+rtpengine Module
|
|
|
|
|
|
Maxim Sobolev
|
|
|
|
|
|
@@ -36,15 +36,15 @@ Richard Fuchs
|
|
|
|
|
|
Sipwise GmbH
|
|
|
|
|
|
- Copyright (c) 2003-2008 Sippy Software, Inc.
|
|
|
+ Copyright © 2003-2008 Sippy Software, Inc.
|
|
|
|
|
|
- Copyright (c) 2005 Voice Sistem SRL
|
|
|
+ Copyright © 2005 Voice Sistem SRL
|
|
|
|
|
|
- Copyright (c) 2009-2014 TuTPro Inc.
|
|
|
+ Copyright © 2009-2014 TuTPro Inc.
|
|
|
|
|
|
- Copyright (c) 2010 VoIPEmbedded Inc.
|
|
|
+ Copyright © 2010 VoIPEmbedded Inc.
|
|
|
|
|
|
- Copyright (c) 2013 Sipwise GmbH
|
|
|
+ Copyright © 2013-2014 Sipwise GmbH
|
|
|
__________________________________________________________________
|
|
|
|
|
|
Table of Contents
|
|
|
@@ -52,7 +52,7 @@ Richard Fuchs
|
|
|
1. Admin Guide
|
|
|
|
|
|
1. Overview
|
|
|
- 2. Multiple RTPProxy usage
|
|
|
+ 2. Multiple RTP proxy usage
|
|
|
3. Dependencies
|
|
|
|
|
|
3.1. Kamailio Modules
|
|
|
@@ -60,22 +60,21 @@ Richard Fuchs
|
|
|
|
|
|
4. Parameters
|
|
|
|
|
|
- 4.1. rtpproxy_sock (string)
|
|
|
- 4.2. rtpproxy_disable_tout (integer)
|
|
|
- 4.3. rtpproxy_tout (integer)
|
|
|
- 4.4. rtpproxy_retr (integer)
|
|
|
+ 4.1. rtpengine_sock (string)
|
|
|
+ 4.2. rtpengine_disable_tout (integer)
|
|
|
+ 4.3. rtpengine_tout (integer)
|
|
|
+ 4.4. rtpengine_retr (integer)
|
|
|
4.5. extra_id_pv (string)
|
|
|
4.6. setid_avp (string)
|
|
|
|
|
|
5. Functions
|
|
|
|
|
|
- 5.1. set_rtp_proxy_set(setid)
|
|
|
- 5.2. rtpproxy_offer([flags [, ip_address]])
|
|
|
- 5.3. rtpproxy_answer([flags [, ip_address]])
|
|
|
- 5.4. rtpproxy_destroy([flags])
|
|
|
- 5.5. unforce_rtp_proxy()
|
|
|
- 5.6. rtpproxy_manage([flags [, ip_address]])
|
|
|
- 5.7. start_recording()
|
|
|
+ 5.1. set_rtpengine_set(setid)
|
|
|
+ 5.2. rtpengine_offer([flags])
|
|
|
+ 5.3. rtpengine_answer([flags])
|
|
|
+ 5.4. rtpengine_delete([flags])
|
|
|
+ 5.5. rtpengine_manage([flags])
|
|
|
+ 5.6. start_recording()
|
|
|
|
|
|
6. Exported Pseudo Variables
|
|
|
|
|
|
@@ -90,17 +89,17 @@ Richard Fuchs
|
|
|
|
|
|
List of Examples
|
|
|
|
|
|
- 1.1. Set rtpproxy_sock parameter
|
|
|
- 1.2. Set rtpproxy_disable_tout parameter
|
|
|
- 1.3. Set rtpproxy_tout parameter
|
|
|
- 1.4. Set rtpproxy_retr parameter
|
|
|
+ 1.1. Set rtpengine_sock parameter
|
|
|
+ 1.2. Set rtpengine_disable_tout parameter
|
|
|
+ 1.3. Set rtpengine_tout parameter
|
|
|
+ 1.4. Set rtpengine_retr parameter
|
|
|
1.5. Set extra_id_pv parameter
|
|
|
1.6. Set setid_avp parameter
|
|
|
- 1.7. set_rtp_proxy_set usage
|
|
|
- 1.8. rtpproxy_offer usage
|
|
|
- 1.9. rtpproxy_answer usage
|
|
|
- 1.10. rtpproxy_destroy usage
|
|
|
- 1.11. rtpproxy_manage usage
|
|
|
+ 1.7. set_rtpengine_set usage
|
|
|
+ 1.8. rtpengine_offer usage
|
|
|
+ 1.9. rtpengine_answer usage
|
|
|
+ 1.10. rtpengine_delete usage
|
|
|
+ 1.11. rtpengine_manage usage
|
|
|
1.12. start_recording usage
|
|
|
1.13. $rtpstat Usage
|
|
|
1.14. nh_enable_rtpp usage
|
|
|
@@ -111,7 +110,7 @@ Chapter 1. Admin Guide
|
|
|
Table of Contents
|
|
|
|
|
|
1. Overview
|
|
|
- 2. Multiple RTPProxy usage
|
|
|
+ 2. Multiple RTP proxy usage
|
|
|
3. Dependencies
|
|
|
|
|
|
3.1. Kamailio Modules
|
|
|
@@ -119,22 +118,21 @@ Chapter 1. Admin Guide
|
|
|
|
|
|
4. Parameters
|
|
|
|
|
|
- 4.1. rtpproxy_sock (string)
|
|
|
- 4.2. rtpproxy_disable_tout (integer)
|
|
|
- 4.3. rtpproxy_tout (integer)
|
|
|
- 4.4. rtpproxy_retr (integer)
|
|
|
+ 4.1. rtpengine_sock (string)
|
|
|
+ 4.2. rtpengine_disable_tout (integer)
|
|
|
+ 4.3. rtpengine_tout (integer)
|
|
|
+ 4.4. rtpengine_retr (integer)
|
|
|
4.5. extra_id_pv (string)
|
|
|
4.6. setid_avp (string)
|
|
|
|
|
|
5. Functions
|
|
|
|
|
|
- 5.1. set_rtp_proxy_set(setid)
|
|
|
- 5.2. rtpproxy_offer([flags [, ip_address]])
|
|
|
- 5.3. rtpproxy_answer([flags [, ip_address]])
|
|
|
- 5.4. rtpproxy_destroy([flags])
|
|
|
- 5.5. unforce_rtp_proxy()
|
|
|
- 5.6. rtpproxy_manage([flags [, ip_address]])
|
|
|
- 5.7. start_recording()
|
|
|
+ 5.1. set_rtpengine_set(setid)
|
|
|
+ 5.2. rtpengine_offer([flags])
|
|
|
+ 5.3. rtpengine_answer([flags])
|
|
|
+ 5.4. rtpengine_delete([flags])
|
|
|
+ 5.5. rtpengine_manage([flags])
|
|
|
+ 5.6. start_recording()
|
|
|
|
|
|
6. Exported Pseudo Variables
|
|
|
|
|
|
@@ -149,45 +147,45 @@ Chapter 1. Admin Guide
|
|
|
|
|
|
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
|
|
|
- the Sipwise ngcp-rtpproxy-ng https://github.com/sipwise/mediaproxy-ng.
|
|
|
- The rtpproxy-ng 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.
|
|
|
+ the Sipwise rtpengine https://github.com/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. Multiple RTPProxy usage
|
|
|
+2. Multiple RTP proxy usage
|
|
|
|
|
|
- The rtpproxy-ng module can support multiple RTP proxies for
|
|
|
+ The rtpengine module can support multiple RTP proxies for
|
|
|
balancing/distribution and control/selection purposes.
|
|
|
|
|
|
The module allows definition of several sets of rtpproxies.
|
|
|
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 "rtpproxy_sock"
|
|
|
+ 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 rtpproxy from the set.
|
|
|
+ the weight of each RTP proxy from the set.
|
|
|
|
|
|
The selection of the set is done from script prior using
|
|
|
- unforce_rtp_proxy(), rtpproxy_offer() or rtpproxy_answer() functions -
|
|
|
- see the set_rtp_proxy_set() function.
|
|
|
+ rtpengine_delete(), rtpengine_offer() or rtpengine_answer() 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 rtpproxy_offer() or
|
|
|
- rtpproxy_manage() function. If forwarding of the requests fails and
|
|
|
+ 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
|
|
|
- rtpproxy_destroy() function.
|
|
|
+ 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 unforce_rtp_proxy(),
|
|
|
- rtpproxy_offer() or rtpproxy_answer() the 0 id set will be used.
|
|
|
+ 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 rtpproxy_offer()/rtpproxy_answer() and unforce_rtpproxy()!! If the
|
|
|
- set was selected using setid_avp, the avp needs to be set only once
|
|
|
- before rtpproxy_offer() or rtpproxy_manage() call.
|
|
|
+ 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.
|
|
|
|
|
|
3. Dependencies
|
|
|
|
|
|
@@ -197,7 +195,7 @@ Chapter 1. Admin Guide
|
|
|
3.1. Kamailio Modules
|
|
|
|
|
|
The following modules must be loaded before this module:
|
|
|
- * tm module - (optional) if you want to have rtpproxy_manage() fully
|
|
|
+ * tm module - (optional) if you want to have rtpengine_manage() fully
|
|
|
functional
|
|
|
|
|
|
3.2. External Libraries or Applications
|
|
|
@@ -208,123 +206,122 @@ Chapter 1. Admin Guide
|
|
|
|
|
|
4. Parameters
|
|
|
|
|
|
- 4.1. rtpproxy_sock (string)
|
|
|
- 4.2. rtpproxy_disable_tout (integer)
|
|
|
- 4.3. rtpproxy_tout (integer)
|
|
|
- 4.4. rtpproxy_retr (integer)
|
|
|
+ 4.1. rtpengine_sock (string)
|
|
|
+ 4.2. rtpengine_disable_tout (integer)
|
|
|
+ 4.3. rtpengine_tout (integer)
|
|
|
+ 4.4. rtpengine_retr (integer)
|
|
|
4.5. extra_id_pv (string)
|
|
|
4.6. setid_avp (string)
|
|
|
|
|
|
-4.1. rtpproxy_sock (string)
|
|
|
+4.1. rtpengine_sock (string)
|
|
|
|
|
|
- Definition of socket(s) used to connect to (a set) RTPProxy. It may
|
|
|
+ Definition of socket(s) used to connect to (a set) RTP proxy. It may
|
|
|
specify a UNIX socket or an IPv4/IPv6 UDP socket.
|
|
|
|
|
|
- Default value is "NONE" (disabled).
|
|
|
+ Default value is “NONE” (disabled).
|
|
|
|
|
|
- Example 1.1. Set rtpproxy_sock parameter
|
|
|
+ Example 1.1. Set rtpengine_sock parameter
|
|
|
...
|
|
|
# single rtproxy
|
|
|
-modparam("rtpproxy-ng", "rtpproxy_sock", "udp:localhost:12221")
|
|
|
+modparam("rtpengine", "rtpengine_sock", "udp:localhost:12221")
|
|
|
# multiple rtproxies for LB
|
|
|
-modparam("rtpproxy-ng", "rtpproxy_sock",
|
|
|
+modparam("rtpengine", "rtpengine_sock",
|
|
|
"udp:localhost:12221 udp:localhost:12222")
|
|
|
# multiple sets of multiple rtproxies
|
|
|
-modparam("rtpproxy-ng", "rtpproxy_sock",
|
|
|
+modparam("rtpengine", "rtpengine_sock",
|
|
|
"1 == udp:localhost:12221 udp:localhost:12222")
|
|
|
-modparam("rtpproxy-ng", "rtpproxy_sock",
|
|
|
+modparam("rtpengine", "rtpengine_sock",
|
|
|
"2 == udp:localhost:12225")
|
|
|
...
|
|
|
|
|
|
-4.2. rtpproxy_disable_tout (integer)
|
|
|
+4.2. rtpengine_disable_tout (integer)
|
|
|
|
|
|
Once an RTP proxy was found unreachable and marked as disabled, the
|
|
|
- rtpproxy-ng module will not attempt to establish communication to that
|
|
|
- RTP proxy for rtpproxy_disable_tout seconds.
|
|
|
+ rtpengine module will not attempt to establish communication to that
|
|
|
+ RTP proxy for rtpengine_disable_tout seconds.
|
|
|
|
|
|
- Default value is "60".
|
|
|
+ Default value is “60”.
|
|
|
|
|
|
- Example 1.2. Set rtpproxy_disable_tout parameter
|
|
|
+ Example 1.2. Set rtpengine_disable_tout parameter
|
|
|
...
|
|
|
-modparam("rtpproxy-ng", "rtpproxy_disable_tout", 20)
|
|
|
+modparam("rtpengine", "rtpengine_disable_tout", 20)
|
|
|
...
|
|
|
|
|
|
-4.3. rtpproxy_tout (integer)
|
|
|
+4.3. rtpengine_tout (integer)
|
|
|
|
|
|
Timeout value in waiting for reply from RTP proxy.
|
|
|
|
|
|
- Default value is "1".
|
|
|
+ Default value is “1”.
|
|
|
|
|
|
- Example 1.3. Set rtpproxy_tout parameter
|
|
|
+ Example 1.3. Set rtpengine_tout parameter
|
|
|
...
|
|
|
-modparam("rtpproxy-ng", "rtpproxy_tout", 2)
|
|
|
+modparam("rtpengine", "rtpengine_tout", 2)
|
|
|
...
|
|
|
|
|
|
-4.4. rtpproxy_retr (integer)
|
|
|
+4.4. rtpengine_retr (integer)
|
|
|
|
|
|
How many times the module should retry to send and receive after
|
|
|
timeout was generated.
|
|
|
|
|
|
- Default value is "5".
|
|
|
+ Default value is “5”.
|
|
|
|
|
|
- Example 1.4. Set rtpproxy_retr parameter
|
|
|
+ Example 1.4. Set rtpengine_retr parameter
|
|
|
...
|
|
|
-modparam("rtpproxy-ng", "rtpproxy_retr", 2)
|
|
|
+modparam("rtpengine", "rtpengine_retr", 2)
|
|
|
...
|
|
|
|
|
|
4.5. extra_id_pv (string)
|
|
|
|
|
|
- The parameter sets the PV defination to use when the "b" parameter is
|
|
|
- used on unforce_rtp_proxy(), rtpproxy_offer(), rtpproxy_answer() or
|
|
|
- rtpproxy_manage() command.
|
|
|
+ The parameter sets the PV defination to use when the “b” parameter is
|
|
|
+ used on rtpengine_delete(), rtpengine_offer(), rtpengine_answer() or
|
|
|
+ rtpengine_manage() command.
|
|
|
|
|
|
- Default is empty, the "b" parameter may not be used then.
|
|
|
+ Default is empty, the “b” parameter may not be used then.
|
|
|
|
|
|
Example 1.5. Set extra_id_pv parameter
|
|
|
...
|
|
|
-modparam("rtpproxy-ng", "extra_id_pv", "$avp(extra_id)")
|
|
|
+modparam("rtpengine", "extra_id_pv", "$avp(extra_id)")
|
|
|
...
|
|
|
|
|
|
4.6. setid_avp (string)
|
|
|
|
|
|
- The parameter defines an AVP that, if set, determines which rtpproxy
|
|
|
- set rtpproxy_offer(), rtpproxy_answer(), rtpproxy_destroy(), and
|
|
|
- rtpproxy_manage() functions use.
|
|
|
+ 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.6. Set setid_avp parameter
|
|
|
...
|
|
|
-modparam("rtpproxy-ng", "setid_avp", "$avp(setid)")
|
|
|
+modparam("rtpengine", "setid_avp", "$avp(setid)")
|
|
|
...
|
|
|
|
|
|
5. Functions
|
|
|
|
|
|
- 5.1. set_rtp_proxy_set(setid)
|
|
|
- 5.2. rtpproxy_offer([flags [, ip_address]])
|
|
|
- 5.3. rtpproxy_answer([flags [, ip_address]])
|
|
|
- 5.4. rtpproxy_destroy([flags])
|
|
|
- 5.5. unforce_rtp_proxy()
|
|
|
- 5.6. rtpproxy_manage([flags [, ip_address]])
|
|
|
- 5.7. start_recording()
|
|
|
+ 5.1. set_rtpengine_set(setid)
|
|
|
+ 5.2. rtpengine_offer([flags])
|
|
|
+ 5.3. rtpengine_answer([flags])
|
|
|
+ 5.4. rtpengine_delete([flags])
|
|
|
+ 5.5. rtpengine_manage([flags])
|
|
|
+ 5.6. start_recording()
|
|
|
|
|
|
-5.1. set_rtp_proxy_set(setid)
|
|
|
+5.1. set_rtpengine_set(setid)
|
|
|
|
|
|
- Sets the Id of the rtpproxy set to be used for the next
|
|
|
- unforce_rtp_proxy(), rtpproxy_offer(), rtpproxy_answer() or
|
|
|
- rtpproxy_manage() command. The parameter can be an integer or a config
|
|
|
+ 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.
|
|
|
|
|
|
This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE,
|
|
|
BRANCH_ROUTE.
|
|
|
|
|
|
- Example 1.7. set_rtp_proxy_set usage
|
|
|
+ Example 1.7. set_rtpengine_set usage
|
|
|
...
|
|
|
-set_rtp_proxy_set("2");
|
|
|
-rtpproxy_offer();
|
|
|
+set_rtpengine_set("2");
|
|
|
+rtpengine_offer();
|
|
|
...
|
|
|
|
|
|
-5.2. rtpproxy_offer([flags [, ip_address]])
|
|
|
+5.2. rtpengine_offer([flags])
|
|
|
|
|
|
Rewrites SDP body to ensure that media is passed through an RTP proxy.
|
|
|
To be invoked on INVITE for the cases the SDPs are in INVITE and 200 OK
|
|
|
@@ -332,66 +329,63 @@ rtpproxy_offer();
|
|
|
|
|
|
Meaning of the parameters is as follows:
|
|
|
* flags - flags to turn on some features.
|
|
|
- + 1 - append first Via branch to Call-ID when sending command to
|
|
|
- rtpproxy. This can be used to create one media session per
|
|
|
- branch on the rtpproxy. When sending a subsequent "delete"
|
|
|
- command to the rtpproxy, you can then stop just the session
|
|
|
- for a specific branch when passing the flag '1' or '2' in the
|
|
|
- "unforce_rtpproxy", 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
|
|
|
- rtpproxy 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 ngcp-mediaproxy-ng rtpproxy at the moment!
|
|
|
- + 2 - append second Via branch to Call-ID when sending command
|
|
|
- to rtpproxy. See flag '1' for its meaning.
|
|
|
- + 3 - behave like flag 1 is set for a request and like flag 2 is
|
|
|
- set for a reply.
|
|
|
- + a - flags that UA from which message is received doesn't
|
|
|
- support symmetric RTP. (automatically sets the 'r' flag)
|
|
|
- + b - append branch specific variable to Call-ID when sending
|
|
|
- command to rtpproxy. This creates one rtpproxy session per
|
|
|
- unique variable. Works similar to the 1, 2 and 3 parameter,
|
|
|
- but is usefull when forking to multiple destinations on
|
|
|
- different address families or network segments, requiring
|
|
|
- different rtpproxy parameters. The variable value is taken
|
|
|
- from the "extra_id_pv". When used, it must be used in every
|
|
|
- call to rtpproxy_manage(), rtpproxy_offer(), rtpproxy_answer()
|
|
|
- and rtpproxy_destroy() with the same contents of the PV. The b
|
|
|
- parameter may not be used in conjunction with the 1, 2 or 3
|
|
|
- parameter to use the Via branch in the Call-ID.
|
|
|
- + l - force "lookup", that is, only rewrite SDP when
|
|
|
+ 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. 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. (automatically sets the 'r'
|
|
|
+ flag)
|
|
|
+ + 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.
|
|
|
- + i, e - these flags specify the direction of the SIP message.
|
|
|
- These flags only make sense when rtpproxy is running in bridge
|
|
|
- mode. 'i' means internal network (LAN), 'e' means external
|
|
|
- network (WAN). 'i' corresponds to rtpproxy's first interface,
|
|
|
- 'e' corresponds to rtpproxy's second interface. You always
|
|
|
- have to specify two flags to define the incoming network and
|
|
|
- the outgoing network. For example, 'ie' should be used for SIP
|
|
|
- message received from the local interface and sent out on the
|
|
|
- external interface, and 'ei' vice versa. Other options are
|
|
|
- 'ii' and 'ee'. So, for example if a SIP requests is processed
|
|
|
- with 'ie' flags, the corresponding response must be processed
|
|
|
- with 'ie' flags.
|
|
|
- For ngcp-mediaproxy-ng, these flags are used to select between
|
|
|
- IPv4 and IPv6 addresses, corresponding to 'i' and 'e'
|
|
|
- respectively. For example, if the request is coming from an
|
|
|
- IPv4 host and is going to an IPv6 host, the flags should be
|
|
|
- specified as 'ie'.
|
|
|
- Note: As rtpproxy in bridge mode s per default asymmetric, you
|
|
|
- have to specify the 'w' flag for clients behind NAT! See also
|
|
|
- above notes!
|
|
|
- + x - this flag an alternative to the 'ie' or 'ei'-flags in
|
|
|
- order to do automatic bridging between IPv4 on the "internal
|
|
|
- network" and IPv6 on the "external network". Instead of
|
|
|
- explicitly instructing the RTP proxy to select a particular
|
|
|
- address family, the distinction is done by the given IP in the
|
|
|
- SDP body by the RTP proxy itself. Not supported by
|
|
|
- ngcp-mediaproxy-ng.
|
|
|
+ + internal, external - these flags specify the direction of the
|
|
|
+ SIP message. These flags only make sense when the RTP proxy is
|
|
|
+ running in bridge mode. “internal” corresponds to the proxy's
|
|
|
+ first interface, “external” corresponds to the RTP proxy's
|
|
|
+ second interface. You always have to specify two flags to
|
|
|
+ define the incoming network and the outgoing network. For
|
|
|
+ example, “internal external” should be used for SIP message
|
|
|
+ received from the local interface and sent out on the external
|
|
|
+ interface, and “external internal” vice versa. Other options
|
|
|
+ are “internal internal” and “external external”. So, for
|
|
|
+ example if a SIP requests is processed with “internal
|
|
|
+ external” flags, the corresponding response must be processed
|
|
|
+ with “internal external” flags.
|
|
|
+ + auto-bridge - this flag an alternative to the “internal” and
|
|
|
+ “external” flags in order to do automatic bridging between
|
|
|
+ IPv4 on the "internal network" and IPv6 on the "external
|
|
|
+ network". Instead of explicitly instructing the RTP proxy to
|
|
|
+ select a particular address family, the distinction is done by
|
|
|
+ the given IP in the SDP body by the RTP proxy itself. Not
|
|
|
+ supported by Sipwise rtpengine.
|
|
|
+ + 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
|
|
|
@@ -399,68 +393,95 @@ rtpproxy_offer();
|
|
|
RFC4091 (ANAT) compatible clients, which suggests having
|
|
|
different m-lines with different IP-protocols grouped
|
|
|
together.
|
|
|
- + f - instructs rtpproxy to ignore marks inserted by another
|
|
|
- rtpproxy in transit to indicate that the session is already
|
|
|
- goes through another proxy. Allows creating a chain of
|
|
|
- proxies.
|
|
|
- + r - flags that IP address in SDP should be trusted. Without
|
|
|
- this flag, rtpproxy ignores address in the SDP and uses source
|
|
|
- address of the SIP message as media address which is passed to
|
|
|
- the RTP proxy.
|
|
|
- + o - flags that IP from the origin description (o=) should be
|
|
|
- also changed.
|
|
|
- + c - flags to change the session-level SDP connection (c=) IP
|
|
|
- if media-description also includes connection information.
|
|
|
- + w - flags that for the UA from which message is received,
|
|
|
- support symmetric RTP must be forced.
|
|
|
- + zNN - requests the RTPproxy 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 RTPproxy 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.
|
|
|
- + + - instructs the RTP proxy to 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.
|
|
|
- Without this flag, 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 an additional ICE candidate. Other
|
|
|
- SDP substitutions (c=, m=, etc) are unaffected by this flag.
|
|
|
- + - - instructs the RTP proxy to discard any ICE attributes and
|
|
|
- not insert any new ones into the SDP. Mutually exclusive with
|
|
|
- the '+' flag.
|
|
|
- + s, S, p, P - 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 "S" flag indicates that SRTP should
|
|
|
- be used, while "s" indicates that SRTP should not be used. "P"
|
|
|
- indicates that the advanced RTCP profile with feedback
|
|
|
- messages should be used, and "p" indicates that the regular
|
|
|
- RTCP profile should be used. As such, the combinations "sp",
|
|
|
- "sP", "Sp" and "SP" select between RTP/AVP, RTP/AVPF, RTP/SAVP
|
|
|
- and RTP/SAVPF, respectively.
|
|
|
- * ip_address - new SDP IP address.
|
|
|
+ + force - instructs the RTP proxy to ignore marks inserted by
|
|
|
+ another RTP proxy in transit to indicate that the session is
|
|
|
+ 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. Without this flag, the RTP proxy ignores address in
|
|
|
+ the SDP and uses source address of the SIP message as media
|
|
|
+ address which is passed to the RTP proxy.
|
|
|
+ + 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.
|
|
|
+ + 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; “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 an additional ICE candidate. Other SDP substitutions
|
|
|
+ (c=, m=, etc) are unaffected by this flag.
|
|
|
+ + RTP, SRTP, 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 SRTP 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, RTP/AVPF, 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.
|
|
|
+ + 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.
|
|
|
|
|
|
This function can be used from ANY_ROUTE.
|
|
|
|
|
|
- Example 1.8. rtpproxy_offer usage
|
|
|
+ Example 1.8. rtpengine_offer usage
|
|
|
route {
|
|
|
...
|
|
|
if (is_method("INVITE")) {
|
|
|
if (has_body("application/sdp")) {
|
|
|
- if (rtpproxy_offer())
|
|
|
+ if (rtpengine_offer())
|
|
|
t_on_reply("1");
|
|
|
} else {
|
|
|
t_on_reply("2");
|
|
|
}
|
|
|
}
|
|
|
if (is_method("ACK") && has_body("application/sdp"))
|
|
|
- rtpproxy_answer();
|
|
|
+ rtpengine_answer();
|
|
|
...
|
|
|
}
|
|
|
|
|
|
@@ -468,7 +489,7 @@ onreply_route[1]
|
|
|
{
|
|
|
...
|
|
|
if (has_body("application/sdp"))
|
|
|
- rtpproxy_answer();
|
|
|
+ rtpengine_answer();
|
|
|
...
|
|
|
}
|
|
|
|
|
|
@@ -476,102 +497,75 @@ onreply_route[2]
|
|
|
{
|
|
|
...
|
|
|
if (has_body("application/sdp"))
|
|
|
- rtpproxy_offer();
|
|
|
+ rtpengine_offer();
|
|
|
...
|
|
|
}
|
|
|
|
|
|
-5.3. rtpproxy_answer([flags [, ip_address]])
|
|
|
+5.3. rtpengine_answer([flags])
|
|
|
|
|
|
Rewrites SDP body to ensure that media is passed through an RTP proxy.
|
|
|
To be invoked on 200 OK for the cases the SDPs are in INVITE and 200 OK
|
|
|
and on ACK when SDPs are in 200 OK and ACK.
|
|
|
|
|
|
- See rtpproxy_answer() function description above for the meaning of the
|
|
|
+ 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.9. rtpproxy_answer usage
|
|
|
+ Example 1.9. rtpengine_answer usage
|
|
|
|
|
|
- See rtpproxy_offer() function example above for example.
|
|
|
+ See rtpengine_offer() function example above for example.
|
|
|
|
|
|
-5.4. rtpproxy_destroy([flags])
|
|
|
+5.4. rtpengine_delete([flags])
|
|
|
|
|
|
Tears down the RTPProxy session for the current call.
|
|
|
|
|
|
+ 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.
|
|
|
|
|
|
- Meaning of the parameters is as follows:
|
|
|
- * flags - flags to turn on some features.
|
|
|
- + 1 - append first Via branch to Call-ID when sending command to
|
|
|
- rtpproxy. This can be used to create one media session per
|
|
|
- branch on the rtpproxy. When sending a subsequent "delete"
|
|
|
- command to the rtpproxy, you can then stop just the session
|
|
|
- for a specific branch when passing the flag '1' or '2' in the
|
|
|
- "unforce_rtpproxy", 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
|
|
|
- rtpproxy gets an "update" command for a new branch, and then a
|
|
|
- "delete" command for the previous branch, which would
|
|
|
- otherwise delete the full call, breaking the subsequent
|
|
|
- "lookup" for the new branch. This flag is only supported by
|
|
|
- the ngcp-mediaproxy-ng rtpproxy at the moment!
|
|
|
- + 2 - append second Via branch to Call-ID when sending command
|
|
|
- to rtpproxy. See flag '1' for its meaning.
|
|
|
- + b - append branch specific variable to Call-ID when sending
|
|
|
- command to rtpproxy. See rtpproxy_offer() for details.
|
|
|
- <listitem>
|
|
|
- </listitem>
|
|
|
- t - do not include To tag to "delete" command to rtpproxy thus
|
|
|
- causing full call to be deleted. Useful for deleting unused
|
|
|
- rtpproxy call when 200 OK is received on a branch, where
|
|
|
- rtpproxy is not needed.
|
|
|
-
|
|
|
- Example 1.10. rtpproxy_destroy usage
|
|
|
-...
|
|
|
-rtpproxy_destroy();
|
|
|
-...
|
|
|
-
|
|
|
-5.5. unforce_rtp_proxy()
|
|
|
-
|
|
|
- Same as rtpproxy_destroy().
|
|
|
-
|
|
|
-5.6. rtpproxy_manage([flags [, ip_address]])
|
|
|
+ Example 1.10. rtpengine_delete usage
|
|
|
+...
|
|
|
+rtpengine_delete();
|
|
|
+...
|
|
|
+
|
|
|
+5.5. rtpengine_manage([flags])
|
|
|
|
|
|
Manage the RTPProxy session - it combines the functionality of
|
|
|
- rtpproxy_offer(), rtpproxy_answer() and unforce_rtpproxy(), detecting
|
|
|
+ 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 rtpproxy_offer(). The flags
|
|
|
- parameter to rtpproxy_manage() can be a configuration variable
|
|
|
+ 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 rtpproxy_offer()
|
|
|
+ * 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
|
|
|
- rtpproxy_answer()
|
|
|
- * If ACK with SDP, then do rtpproxy_answer()
|
|
|
+ rtpengine_answer()
|
|
|
+ * If ACK with SDP, then do rtpengine_answer()
|
|
|
* If BYE or CANCEL, or called within a FAILURE_ROUTE[], then do
|
|
|
- unforce_rtpproxy()
|
|
|
- * If reply to INVITE with code >= 300 do unforce_rtpproxy()
|
|
|
+ rtpengine_delete()
|
|
|
+ * If reply to INVITE with code >= 300 do rtpengine_delete()
|
|
|
* If reply with SDP to INVITE having code 1xx and 2xx, then do
|
|
|
- rtpproxy_answer() if the request had SDP or tm is not loaded,
|
|
|
- otherwise do rtpproxy_offer()
|
|
|
+ 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.11. rtpproxy_manage usage
|
|
|
+ Example 1.11. rtpengine_manage usage
|
|
|
...
|
|
|
-rtpproxy_manage();
|
|
|
+rtpengine_manage();
|
|
|
...
|
|
|
|
|
|
-5.7. start_recording()
|
|
|
+5.6. start_recording()
|
|
|
|
|
|
- This function will send a signal to the RTP Proxy to record the RTP
|
|
|
- stream on the RTP Proxy. This function is not supported by
|
|
|
- ngcp-mediaproxy-ng at the moment!
|
|
|
+ This function will send a signal to the RTP proxy to record the RTP
|
|
|
+ stream on the RTP proxy. This function is not supported by Sipwise
|
|
|
+ rtpengine at the moment!
|
|
|
|
|
|
This function can be used from REQUEST_ROUTE and ONREPLY_ROUTE.
|
|
|
|
|
|
@@ -586,10 +580,10 @@ start_recording();
|
|
|
|
|
|
6.1. $rtpstat
|
|
|
|
|
|
- Returns the RTP Statistics from the RTP Proxy. The RTP Statistics from
|
|
|
- the RTP Proxy are provided as a string and it does contain several
|
|
|
+ Returns the RTP statistics from the RTP proxy. The RTP statistics from
|
|
|
+ the RTP proxy are provided as a string and it does contain several
|
|
|
packet counters. The statistics must be retrieved before the session is
|
|
|
- deleted (before unforce_rtpproxy()).
|
|
|
+ deleted (before rtpengine_delete()).
|
|
|
|
|
|
Example 1.13. $rtpstat Usage
|
|
|
...
|
|
|
@@ -603,16 +597,16 @@ start_recording();
|
|
|
|
|
|
7.1. nh_enable_rtpp
|
|
|
|
|
|
- Enables a rtp proxy if parameter value is greater than 0. Disables it
|
|
|
+ Enables a RTP proxy if parameter value is greater than 0. Disables it
|
|
|
if a zero value is given.
|
|
|
|
|
|
- The first parameter is the rtp proxy url (exactly as defined in the
|
|
|
+ The first parameter is the RTP proxy url (exactly as defined in the
|
|
|
config file).
|
|
|
|
|
|
The second parameter value must be a number in decimal.
|
|
|
|
|
|
- NOTE: if a rtpproxy is defined multiple times (in the same or diferente
|
|
|
- sete), all of its instances will be enables/disabled.
|
|
|
+ NOTE: if a RTP proxy is defined multiple times (in the same or
|
|
|
+ diferente sete), all of its instances will be enables/disabled.
|
|
|
|
|
|
Example 1.14. nh_enable_rtpp usage
|
|
|
...
|
|
|
@@ -621,7 +615,7 @@ $ kamctl fifo nh_enable_rtpp udp:192.168.2.133:8081 0
|
|
|
|
|
|
7.2. nh_show_rtpp
|
|
|
|
|
|
- Displays all the rtp proxies and their information: set and status
|
|
|
+ Displays all the RTP proxies and their information: set and status
|
|
|
(disabled or not, weight and recheck_ticks).
|
|
|
|
|
|
No parameter.
|
|
|
@@ -633,45 +627,64 @@ $ kamctl fifo nh_show_rtpp
|
|
|
|
|
|
Chapter 2. Frequently Asked Questions
|
|
|
|
|
|
- 2.1. What happend with "rtpproxy_disable" parameter?
|
|
|
+ 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.
|
|
|
|
|
|
- What happend with "rtpproxy_disable" parameter?
|
|
|
+ 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");
|
|
|
|
|
|
- It was removed as it became obsolete - now "rtpproxy_sock" can take
|
|
|
- empty value to disable the rtpproxy functionality.
|
|
|
+ Finally, if you were using the second paramater (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?
|
|
|
+ Where can I find more about Kamailio?
|
|
|
|
|
|
- Take a look at http://www.kamailio.org/.
|
|
|
+ Take a look at http://www.kamailio.org/.
|
|
|
|
|
|
2.3.
|
|
|
|
|
|
- Where can I post a question about this module?
|
|
|
+ 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 -
|
|
|
- http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
|
|
|
- * Developer Mailing List -
|
|
|
- http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
|
|
|
+ First at all check if your question was already answered on one of our
|
|
|
+ mailing lists:
|
|
|
+ * User Mailing List -
|
|
|
+ http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
|
|
|
+ * Developer Mailing List -
|
|
|
+ http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
|
|
|
|
|
|
- E-mails regarding any stable Kamailio release should be sent to
|
|
|
- <[email protected]> and e-mails regarding development
|
|
|
- versions should be sent to <[email protected]>.
|
|
|
+ E-mails regarding any stable Kamailio release should be sent to
|
|
|
+ <[email protected]> and e-mails regarding development
|
|
|
+ versions should be sent to <[email protected]>.
|
|
|
|
|
|
- If you want to keep the mail private, send it to
|
|
|
- <[email protected]>.
|
|
|
+ If you want to keep the mail private, send it to
|
|
|
+ <[email protected]>.
|
|
|
|
|
|
2.4.
|
|
|
|
|
|
- How can I report a bug?
|
|
|
+ How can I report a bug?
|
|
|
|
|
|
- Please follow the guidelines provided at:
|
|
|
- http://sip-router.org/tracker.
|
|
|
+ Please follow the guidelines provided at:
|
|
|
+ http://sip-router.org/tracker.
|
Richard Fuchs