Module: sip-router
Branch: master
Commit: 9556f8a37575c8f9a3a212f07e9fa9632116e06e
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=9556f8a…
Author: Charles Chance <charles.chance(a)sipcentric.com>
Committer: Charles Chance <charles.chance(a)sipcentric.com>
Date: Wed Sep 10 00:41:48 2014 +0100
dmq: update documentation with new functions dmq_t_replicate() and dmq_is_from_node()
---
modules/dmq/README | 50 +++++++++++++++++++++++++++++++++
modules/dmq/doc/dmq_admin.xml | 61 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 111 insertions(+), 0 deletions(-)
diff --git a/modules/dmq/README b/modules/dmq/README
index 7f3fb6b..8bc19e4 100644
--- a/modules/dmq/README
+++ b/modules/dmq/README
@@ -41,6 +41,8 @@ Charles Chance
4.1. dmq_handle_message()
4.2. dmq_send_message(peer, node, body, content_type)
4.3. dmq_bcast_message(peer, body, content_type)
+ 4.4. dmq_t_replicate([skip_loop_test])
+ 4.5. dmq_is_from_node()
2. Developer Guide
@@ -63,6 +65,8 @@ Charles Chance
1.5. dmq_handle_message usage
1.6. dmq_send_message usage
1.7. dmq_bcast_message usage
+ 1.8. dmq_t_replicate usage
+ 1.9. dmq_is_from_node usage
2.1. dmq_api_t structure
2.2. register_dmq_peer usage
2.3. bcast_message usage
@@ -90,6 +94,8 @@ Chapter 1. Admin Guide
4.1. dmq_handle_message()
4.2. dmq_send_message(peer, node, body, content_type)
4.3. dmq_bcast_message(peer, body, content_type)
+ 4.4. dmq_t_replicate([skip_loop_test])
+ 4.5. dmq_is_from_node()
1. Overview
@@ -183,6 +189,8 @@ modparam("dmq", "ping_interval", 90)
4.1. dmq_handle_message()
4.2. dmq_send_message(peer, node, body, content_type)
4.3. dmq_bcast_message(peer, body, content_type)
+ 4.4. dmq_t_replicate([skip_loop_test])
+ 4.5. dmq_is_from_node()
4.1. dmq_handle_message()
@@ -234,6 +242,48 @@ text/plain");
dmq_bcast_message("peer_name", "Message body...", "text/plain");
...
+4.4. dmq_t_replicate([skip_loop_test])
+
+ Replicates the current SIP message to all active nodes (except self).
+ Useful for replicating REGISTER, PUBLISH etc. in a clustered
+ environment.
+
+ Meaning of parameters:
+ * skip_loop_test - by default, DMQ checks the source IP of the
+ message prior to replication, to ensure it has not been sent by
+ another DMQ node (to avoid infinite loops). If this optional
+ parameter is set to "1", the loop test is not performed. This makes
+ sense, from a performance perspective, if you have already
+ performed the necessary checks in the config script (see
+ dmq_is_from_node()).
+
+ This function can be used from REQUEST_ROUTE only.
+
+ Example 1.8. dmq_t_replicate usage
+...
+ dmq_t_replicate();
+...
+
+4.5. dmq_is_from_node()
+
+ Checks whether the current message has been sent by another DMQ node in
+ the cluster.
+
+ This function can be used from REQUEST_ROUTE only.
+
+ Example 1.9. dmq_is_from_node usage
+...
+ # Example REGISTER block
+ if (dmq_is_from_node()) {
+ # Already authenticated, just save contact...
+ } else {
+ # Authenticate, save contact etc.
+ # Assuming all successful...
+ dmq_t_replicate("1"); # Already checked source, don't perform lo
+op test again
+ }
+...
+
Chapter 2. Developer Guide
Table of Contents
diff --git a/modules/dmq/doc/dmq_admin.xml b/modules/dmq/doc/dmq_admin.xml
index 0192a21..7eabc1a 100644
--- a/modules/dmq/doc/dmq_admin.xml
+++ b/modules/dmq/doc/dmq_admin.xml
@@ -244,6 +244,67 @@ modparam("dmq", "ping_interval", 90)
</programlisting>
</example>
</section>
+ <section id="dmq.f.dmq_t_replicate">
+ <title>
+ <function moreinfo="none">dmq_t_replicate([skip_loop_test])</function>
+ </title>
+ <para>
+ Replicates the current SIP message to all active nodes (except self). Useful for replicating
+ REGISTER, PUBLISH etc. in a clustered environment.
+ </para>
+ <para>Meaning of parameters:</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <emphasis>skip_loop_test</emphasis> - by default, DMQ checks the source IP of the
+ message prior to replication, to ensure it has not been sent by another DMQ node
+ (to avoid infinite loops). If this optional parameter is set to "1", the loop test
+ is not performed. This makes sense, from a performance perspective, if you have
+ already performed the necessary checks in the config script (see dmq_is_from_node()).
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ This function can be used from REQUEST_ROUTE only.
+ </para>
+
+ <example>
+ <title><function>dmq_t_replicate</function> usage</title>
+ <programlisting format="linespecific">
+...
+ dmq_t_replicate();
+...
+ </programlisting>
+ </example>
+ </section>
+ <section id="dmq.f.dmq_is_from_node">
+ <title>
+ <function moreinfo="none">dmq_is_from_node()</function>
+ </title>
+ <para>
+ Checks whether the current message has been sent by another DMQ node in the cluster.
+ </para>
+ <para>
+ This function can be used from REQUEST_ROUTE only.
+ </para>
+
+ <example>
+ <title><function>dmq_is_from_node</function> usage</title>
+ <programlisting format="linespecific">
+...
+ # Example REGISTER block
+ if (dmq_is_from_node()) {
+ # Already authenticated, just save contact...
+ } else {
+ # Authenticate, save contact etc.
+ # Assuming all successful...
+ dmq_t_replicate("1"); # Already checked source, don't perform loop test again
+ }
+...
+ </programlisting>
+ </example>
+ </section>
+
</section>
</chapter>
Module: sip-router
Branch: master
Commit: 1110d4e6b5ec2f949951c9433a80bced778272d9
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=1110d4e…
Author: Juha Heinanen <jh(a)tutpro.com>
Committer: Juha Heinanen <jh(a)tutpro.com>
Date: Tue Sep 9 20:41:47 2014 +0300
modules/rtpengine: generated README
---
modules/rtpengine/README | 75 ++++++++++++++++++++++++++++++---------------
1 files changed, 50 insertions(+), 25 deletions(-)
diff --git a/modules/rtpengine/README b/modules/rtpengine/README
index 760ac4b..b38d92c 100644
--- a/modules/rtpengine/README
+++ b/modules/rtpengine/README
@@ -69,7 +69,7 @@ Richard Fuchs
5. Functions
- 5.1. set_rtpengine_set(setid)
+ 5.1. set_rtpengine_set(setid[, setid])
5.2. rtpengine_offer([flags])
5.3. rtpengine_answer([flags])
5.4. rtpengine_delete([flags])
@@ -127,7 +127,7 @@ Chapter 1. Admin Guide
5. Functions
- 5.1. set_rtpengine_set(setid)
+ 5.1. set_rtpengine_set(setid[, setid])
5.2. rtpengine_offer([flags])
5.3. rtpengine_answer([flags])
5.4. rtpengine_delete([flags])
@@ -298,20 +298,32 @@ modparam("rtpengine", "setid_avp", "$avp(setid)")
5. Functions
- 5.1. set_rtpengine_set(setid)
+ 5.1. set_rtpengine_set(setid[, 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_rtpengine_set(setid)
+5.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 is supported by all rtpengine commands except rtpengine_manage().
+
This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE,
BRANCH_ROUTE.
@@ -324,8 +336,8 @@ rtpengine_offer();
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
- and on 200 OK when SDPs are in 200 OK and ACK.
+ 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.
Meaning of the parameters is as follows:
* flags - flags to turn on some features.
@@ -351,24 +363,29 @@ rtpengine_offer();
"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)
+ doesn't support symmetric RTP. Disables learning of endpoint
+ addresses in the Sipwise rtpengine proxy.
+ 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.
- + 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.
+ + 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.
+ 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
@@ -407,7 +424,8 @@ rtpengine_offer();
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.
+ 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
@@ -424,7 +442,7 @@ rtpengine_offer();
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
+ 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
@@ -469,6 +487,13 @@ rtpengine_offer();
+ 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.
This function can be used from ANY_ROUTE.
@@ -507,8 +532,8 @@ onreply_route[2]
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.
+ 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.
i would like to return to rtpengine trust-address flag. README says:
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.
the first part makes sense, i.e., if the flag is present, then ip
address in the sdp is trusted.
the second part does not make sense to me and neither does "received
from" key of request passed to rtpengine.
rtpengine doc tells about "received from":
Contains a list of exactly two elements. The first element denotes the
address family and the second element is the SIP message's source
address itself. The address family can be one of IP4 or IP6. Used if
neither the trust address flag nor the media address key is present.
there is at least two reasons why it does not make sense to pass source
ip address of sip request to rtpengine:
1) the proxy that is calling rtpengine_offer() may not be the first hop
proxy of the sip ua.
2) even when sip proxy is the first hop, sip ua may not use the same ip
address for sip signaling and rtp media
so what is the reason for the existence of "received from" key? is
there anything lost if the key is removed? if not, then lets get rid of
it in order to simplify things and to avoid confusion.
-- juha
Hi Daniel,
historically, it started with db_kazoo but over the time it was getting
less related to db_ as we moved to a more generic module implementation.
we already had the discussion internally and we agree that kazoo would be
fine for renaming the module.
we will rename db_kazoo to kazoo.
Thanks
Module: sip-router
Branch: master
Commit: e5c9f006060b5b4d00c9ab56f25521debee32216
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=e5c9f00…
Author: Richard Good <richard.good(a)smilecoms.com>
Committer: Richard Good <richard.good(a)smilecoms.com>
Date: Tue Sep 9 16:56:00 2014 +0200
modules/ims_qos: store AAR flow descriptions in CDP session
When flow_descriptions are installed save the active and new
This allows Rx to fallback to previous flow descriptions if there is an upstream failure
---
modules/ims_qos/cdpeventprocessor.c | 3 +-
modules/ims_qos/mod.c | 192 ++++++++++++++++++++++++++---
modules/ims_qos/mod.h | 2 +-
modules/ims_qos/rx_aar.c | 236 ++++++++++++++++++++++++++++++++---
modules/ims_qos/rx_aar.h | 5 +
modules/ims_qos/rx_authdata.c | 230 +++++++++++++++++++++++++++++++++-
modules/ims_qos/rx_authdata.h | 26 ++++-
7 files changed, 652 insertions(+), 42 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=e5c…
Module: sip-router
Branch: master
Commit: e6591dc75d34e8522060ea71148b4cdcae139234
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=e6591dc…
Author: Richard Fuchs <rfuchs(a)sipwise.com>
Committer: Richard Fuchs <rfuchs(a)sipwise.com>
Date: Tue Sep 9 10:37:53 2014 -0400
rtpengine: docs update
---
modules/rtpengine/doc/rtpengine_admin.xml | 46 +++++++++++++++--------------
1 files changed, 24 insertions(+), 22 deletions(-)
diff --git a/modules/rtpengine/doc/rtpengine_admin.xml b/modules/rtpengine/doc/rtpengine_admin.xml
index 7907fb5..fdc9a2d 100644
--- a/modules/rtpengine/doc/rtpengine_admin.xml
+++ b/modules/rtpengine/doc/rtpengine_admin.xml
@@ -288,8 +288,8 @@ rtpengine_offer();
<para>
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 and on 200 OK
- when SDPs are in 200 OK and ACK.
+ 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.
</para>
<para>Meaning of the parameters is as follows:</para>
<itemizedlist>
@@ -325,7 +325,8 @@ rtpengine_offer();
</para></listitem>
<listitem><para>
<emphasis>asymmetric</emphasis> - flags that UA from which message is
- received doesn't support symmetric RTP. (automatically sets the 'r' flag)
+ received doesn't support symmetric &rtp;. Disables learning of endpoint addresses
+ in the Sipwise rtpengine proxy.
</para></listitem>
<listitem><para>
<emphasis>force-answer</emphasis> - force <quote>answer</quote>, that is,
@@ -359,8 +360,8 @@ rtpengine_offer();
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.
+ family, the distinction is done by the given IP in the &sdp; body by
+ the &rtp; proxy itself. Not supported by Sipwise rtpengine.
</para></listitem>
<listitem><para>
<emphasis>address-family=...</emphasis> - instructs the &rtp; proxy that the
@@ -387,10 +388,10 @@ rtpengine_offer();
a chain of proxies. Not supported and ignored by Sipwise rtpengine.
</para></listitem>
<listitem><para>
- <emphasis>trust-address</emphasis> - flags that IP address in SDP should
+ <emphasis>trust-address</emphasis> - 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.
+ the &sdp; and uses source address of the &sip; message as media
+ address which is passed to the &rtp; proxy.
</para></listitem>
<listitem><para>
<emphasis>replace-origin</emphasis> - flags that IP from the origin
@@ -398,18 +399,19 @@ rtpengine_offer();
</para></listitem>
<listitem><para>
<emphasis>replace-session-connection</emphasis> - flags to change the session-level
- SDP connection (c=) IP if media description also includes
+ &sdp; connection (c=) IP if media description also includes
connection information.
</para></listitem>
<listitem><para>
<emphasis>symmetric</emphasis> - flags that for the UA from which
- message is received, support symmetric RTP must be forced.
+ message is received, support symmetric &rtp; must be forced. Does nothing with
+ the Sipwise rtpengine proxy as it is the default.
</para></listitem>
<listitem><para>
<emphasis>repacketize=NN</emphasis> - requests the &rtp; proxy to perform
- re-packetization of RTP traffic coming from the UA which
+ 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
+ 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
@@ -426,7 +428,7 @@ rtpengine_offer();
discard any ICE attributes already present in the &sdp; body
and then generate and insert new ICE data, leaving itself
as the <emphasis>only</emphasis> ICE candidates;
- <quote>force_relay</quote> -
+ <quote>force-relay</quote> -
discard any <quote>relay</quote> type ICE attributes already present
in the &sdp; body and then generate and insert itself
as the <emphasis>only</emphasis> ICE <quote>relay</quote> candidates;
@@ -488,7 +490,7 @@ rtpengine_offer();
be used in the &sdp; body. Address family is detected automatically.
</para></listitem>
<listitem><para>
- <emphasis>TOS=...</emphasis> - change the IP TOS value for all outgoing RTP
+ <emphasis>TOS=...</emphasis> - change the IP TOS value for all outgoing &rtp;
packets within the entire call in both directions. Only honoured in an
<quote>offer</quote>, ignored for an <quote>answer</quote>. Valid values are
0 through 255, given in decimal. If this option is not specified, the TOS
@@ -544,8 +546,8 @@ onreply_route[2]
<para>
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.
+ 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.
</para>
<para>
See rtpengine_offer() function description above for the meaning of the
@@ -606,19 +608,19 @@ rtpengine_delete();
<itemizedlist>
<listitem>
<para>
- If INVITE with SDP, then do <function>rtpengine_offer()</function>
+ If INVITE with &sdp;, then do <function>rtpengine_offer()</function>
</para>
</listitem>
<listitem>
<para>
- If INVITE with SDP, when the tm module is loaded, mark transaction with
+ 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
<function>rtpengine_answer()</function>
</para>
</listitem>
<listitem>
<para>
- If ACK with SDP, then do <function>rtpengine_answer()</function>
+ If ACK with &sdp;, then do <function>rtpengine_answer()</function>
</para>
</listitem>
<listitem>
@@ -633,8 +635,8 @@ rtpengine_delete();
</listitem>
<listitem>
<para>
- If reply with SDP to INVITE having code 1xx and 2xx, then
- do <function>rtpengine_answer()</function> if the request had SDP or tm is not loaded,
+ If reply with &sdp; to INVITE having code 1xx and 2xx, then
+ do <function>rtpengine_answer()</function> if the request had &sdp; or tm is not loaded,
otherwise do <function>rtpengine_offer()</function>
</para>
</listitem>
@@ -659,7 +661,7 @@ rtpengine_manage();
</title>
<para>
This function will send a signal to the &rtp; proxy to record
- the RTP stream on the &rtp; proxy.
+ the &rtp; stream on the &rtp; proxy.
<emphasis>This function is not supported by Sipwise rtpengine at the moment!</emphasis>
</para>
<para>