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>
Module: sip-router
Branch: master
Commit: d54bcfad39f6b3f79a826cab4df83bb7eea189a9
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=d54bcfa…
Author: Richard Fuchs <rfuchs(a)sipwise.com>
Committer: Richard Fuchs <rfuchs(a)sipwise.com>
Date: Tue Sep 9 10:30:45 2014 -0400
rtpengine: support arbitrary direction= flags for interface bridging
---
modules/rtpengine/doc/rtpengine_admin.xml | 32 ++++++++++++++++------------
modules/rtpengine/rtpengine.c | 2 +
2 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/modules/rtpengine/doc/rtpengine_admin.xml b/modules/rtpengine/doc/rtpengine_admin.xml
index 3a82e8b..7907fb5 100644
--- a/modules/rtpengine/doc/rtpengine_admin.xml
+++ b/modules/rtpengine/doc/rtpengine_admin.xml
@@ -334,20 +334,24 @@ rtpengine_offer();
completed.
</para></listitem>
<listitem><para>
- <emphasis>internal, external</emphasis> - these flags specify the direction of
- the &sip; message. These flags only make sense when the &rtp; proxy is running
- in bridge mode. <quote>internal</quote> corresponds to the proxy's first
- interface, <quote>external</quote> 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, <quote>internal
- external</quote> should be
- used for &sip; message received from the local interface and sent out on the
- external interface, and <quote>external internal</quote> vice versa. Other
- options are <quote>internal internal</quote> and <quote>external
- external</quote>.
- So, for example if a &sip; requests is processed with <quote>internal
- external</quote> flags, the corresponding
- response must be processed with <quote>internal external</quote> flags.
+ <emphasis>direction=...</emphasis> - 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
+ <quote>direction=priv direction=pub</quote> if those two logical network
+ interfaces were called <quote>priv</quote> and <quote>pub</quote> 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.
+ </para></listitem>
+ <listitem><para>
+ <emphasis>internal, external</emphasis> - shorthand for
+ <quote>direction=internal</quote> and <quote>direction=external</quote>
+ respectively. Useful for brevity or as legacy option if the &rtp; proxy only
+ supports two network interfaces instead of multiple, arbitrarily named ones.
</para></listitem>
<listitem><para>
<emphasis>auto-bridge</emphasis> - this flag an alternative to the
diff --git a/modules/rtpengine/rtpengine.c b/modules/rtpengine/rtpengine.c
index e47c2ea..063e3d1 100644
--- a/modules/rtpengine/rtpengine.c
+++ b/modules/rtpengine/rtpengine.c
@@ -1240,6 +1240,8 @@ static int parse_flags(struct ng_flags_parse *ng_flags, struct sip_msg *msg, enu
ng_flags->transport = 0x103;
goto next;
}
+ else if (str_eq(&key, "direction"))
+ bencode_list_add_str(ng_flags->direction, &val);
break;
case 10:
Module: sip-router
Branch: master
Commit: 4776b44ea9c5546c37fea9f3886148a17c735fe5
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=4776b44…
Author: Elena-Ramona Modroiu <ramona(a)asipto.com>
Committer: Elena-Ramona Modroiu <ramona(a)asipto.com>
Date: Tue Sep 9 15:24:47 2014 +0200
htable: documentation for iterator functions
---
modules/htable/README | 73 ++++++++++++++++++++++++++++
modules/htable/doc/htable_admin.xml | 91 +++++++++++++++++++++++++++++++++++
2 files changed, 164 insertions(+), 0 deletions(-)
diff --git a/modules/htable/README b/modules/htable/README
index 7a7c3cf..5a27593 100644
--- a/modules/htable/README
+++ b/modules/htable/README
@@ -61,6 +61,9 @@ Ovidiu Sas
4.4. sht_reset(htable)
4.5. sht_lock(htable=>key)
4.6. sht_unlock(htable=>key)
+ 4.7. sht_iterator_start(iname, hname)
+ 4.8. sht_iterator_end(iname)
+ 4.9. sht_iterator_next(iname)
5. Exported pseudo-variables
6. MI Commands
@@ -109,6 +112,9 @@ Ovidiu Sas
1.20. sht_reset usage
1.21. sht_lock usage
1.22. sht_unlock usage
+ 1.23. sht_iterator_start usage
+ 1.24. sht_iterator_end usage
+ 1.25. sht_iterator_next usage
Chapter 1. Admin Guide
@@ -145,6 +151,9 @@ Chapter 1. Admin Guide
4.4. sht_reset(htable)
4.5. sht_lock(htable=>key)
4.6. sht_unlock(htable=>key)
+ 4.7. sht_iterator_start(iname, hname)
+ 4.8. sht_iterator_end(iname)
+ 4.9. sht_iterator_next(iname)
5. Exported pseudo-variables
6. MI Commands
@@ -606,6 +615,9 @@ modparam("htable", "enable_dmq", 1)
4.4. sht_reset(htable)
4.5. sht_lock(htable=>key)
4.6. sht_unlock(htable=>key)
+ 4.7. sht_iterator_start(iname, hname)
+ 4.8. sht_iterator_end(iname)
+ 4.9. sht_iterator_next(iname)
4.1. sht_print()
@@ -682,6 +694,67 @@ $sht(ha=>test) = $sht(ha=>test) + 10;
sht_unlock("ha=>test");
...
+4.7. sht_iterator_start(iname, hname)
+
+ Start an iterator for hash table named by the value of parameter hname.
+ The parameter iname is used to identify the iterator. There can be up
+ to 4 iterators at the same time, with different name.
+
+ Both parameters can be dynamic strings with variables.
+
+ IMPORTANT: the slot of the hash table is left locked when retrieving in
+ item. Therefore be sure you do not update the content of the hash table
+ in between sht_iterator_start() and sht_iterator_end(), because it may
+ end up in dead lock.
+
+ This function can be used from ANY_ROUTE.
+
+ Example 1.23. sht_iterator_start usage
+...
+sht_iterator_start("i1", "h1");
+...
+
+4.8. sht_iterator_end(iname)
+
+ Close the iterator identified by iname parameter and release the hash
+ table slot aquired by the iterator. The iname value must be the same
+ used for sht_iterator_start().
+
+ The parameter can be dynamic string with variables.
+
+ This function can be used from ANY_ROUTE.
+
+ Example 1.24. sht_iterator_end usage
+...
+sht_iterator_end("i1");
+...
+
+4.9. sht_iterator_next(iname)
+
+ Move the iterator to the next item in hash table. It must be called
+ also after sht_iterator_start() to get the first item in the hash
+ table. Items are returned as they are found in the hash table slot,
+ starting with the first slot.
+
+ The return code is false when there is no (more) item in the hash
+ table.
+
+ The item name and value are accessible via variables: $shtitkey(iname)
+ and $shtitval(iname).
+
+ The parameter can be dynamic string with variables.
+
+ This function can be used from ANY_ROUTE.
+
+ Example 1.25. sht_iterator_next usage
+...
+ sht_iterator_start("i1", "h1");
+ while(sht_iterator_next("i1")) {
+ xlog("h1[$shtitkey(i1)] is: $shtitval(i1)\n");
+ }
+ sht_iterator_end("i1");
+...
+
5. Exported pseudo-variables
* $sht(htable=>key)
diff --git a/modules/htable/doc/htable_admin.xml b/modules/htable/doc/htable_admin.xml
index 6427a28..bfba088 100644
--- a/modules/htable/doc/htable_admin.xml
+++ b/modules/htable/doc/htable_admin.xml
@@ -770,6 +770,97 @@ sht_unlock("ha=>test");
</programlisting>
</example>
</section>
+ <section id="htable.f.sht_iterator_start">
+ <title>
+ <function moreinfo="none">sht_iterator_start(iname, hname)</function>
+ </title>
+ <para>
+ Start an iterator for hash table named by the value of parameter
+ hname. The parameter iname is used to identify the iterator. There
+ can be up to 4 iterators at the same time, with different name.
+ </para>
+ <para>
+ Both parameters can be dynamic strings with variables.
+ </para>
+ <para>
+ IMPORTANT: the slot of the hash table is left locked when
+ retrieving in item. Therefore be sure you do not update the
+ content of the hash table in between sht_iterator_start()
+ and sht_iterator_end(), because it may end up in dead lock.
+ </para>
+ <para>
+ This function can be used from ANY_ROUTE.
+ </para>
+ <example>
+ <title><function>sht_iterator_start</function> usage</title>
+ <programlisting format="linespecific">
+...
+sht_iterator_start("i1", "h1");
+...
+</programlisting>
+ </example>
+ </section>
+ <section id="htable.f.sht_iterator_end">
+ <title>
+ <function moreinfo="none">sht_iterator_end(iname)</function>
+ </title>
+ <para>
+ Close the iterator identified by iname parameter and release
+ the hash table slot aquired by the iterator. The iname value
+ must be the same used for sht_iterator_start().
+ </para>
+ <para>
+ The parameter can be dynamic string with variables.
+ </para>
+ <para>
+ This function can be used from ANY_ROUTE.
+ </para>
+ <example>
+ <title><function>sht_iterator_end</function> usage</title>
+ <programlisting format="linespecific">
+...
+sht_iterator_end("i1");
+...
+</programlisting>
+ </example>
+ </section>
+ <section id="htable.f.sht_iterator_next">
+ <title>
+ <function moreinfo="none">sht_iterator_next(iname)</function>
+ </title>
+ <para>
+ Move the iterator to the next item in hash table. It must
+ be called also after sht_iterator_start() to get the first
+ item in the hash table. Items are returned as they are found
+ in the hash table slot, starting with the first slot.
+ </para>
+ <para>
+ The return code is false when there is no (more) item in the
+ hash table.
+ </para>
+ <para>
+ The item name and value are accessible via variables:
+ $shtitkey(iname) and $shtitval(iname).
+ </para>
+ <para>
+ The parameter can be dynamic string with variables.
+ </para>
+ <para>
+ This function can be used from ANY_ROUTE.
+ </para>
+ <example>
+ <title><function>sht_iterator_next</function> usage</title>
+ <programlisting format="linespecific">
+...
+ sht_iterator_start("i1", "h1");
+ while(sht_iterator_next("i1")) {
+ xlog("h1[$shtitkey(i1)] is: $shtitval(i1)\n");
+ }
+ sht_iterator_end("i1");
+...
+</programlisting>
+ </example>
+ </section>
</section>
<section>
<title>Exported pseudo-variables</title>
i made a mistake when i introduced ICE=force_relay flag. for
consistency, the flag should have been ICE=force-relay.
is it too late to fix the name?
-- juha