Hi,
when using sr.pv.get() in app_lua the pv value is not always returned.
Lua code is:
local fscript = sr.pv.get("$(sht(myscripts=>" .. args["filterid"] .."))")
if(fscript) then
sr.log("info","Filterscript is " .. fscript)
else
sr.log("warn","fscript not found!")
end
And log shows:
app_lua [app_lua_sr.c:888]: pv get: (sht(myscripts=>1))
<core> [pvapi.c:318]: pvar [$(sht(myscripts=>1))] found in cache
WARNING: app_lua [app_lua_sr.c:99]: fscript not found!
So the pv is being discovered in the pv cache, but sr.pv.get() returns
no value.
I think the problem occurs especially in the case, when using sht_reload
mi command. So I have had a short look into htable.c and I did not find
any code, that clears the pv cache... is that necessary/may the reason
for the problem, that pv is found in pv cache but nothing returned?
(kamailio 3.2.3)
Thanks for any ideas...
Cheers
Jasmin
Hi,
in kamailio 3.3 the presence DB mode parameters "subs_db_mode",
"publ_cache" and "notifier_processes" control how the module stores
presentity and watcher info in DB.
If they have been set to the following values:
subs_db_mode=3
publ_cache=0
notifier_processes=3
the following query is executed >10 times/second (mysql log):
"select presentity_uri,callid,to_tag,from_tag,event from
kamailio_active_watchers where updated=123 AND event<>'presence.winfo'"
According to the notifier_poll_rate default value (==10) and the formula
in the documentation
1/(waitn_time * notifier_poll_rate * notifier_processes)
That results in 1/(5*10*3) == 1/150
So is it really regular behaviour, if the query is performed that often?
What about using triggers in that situation?
Additionally I have noticed, that only one subscriber gets notified, if
a presentity changes although all subcribers have been stored correctly
in active_watchers.
When I set notifier_processes to 0 (old behaviour) every subscriber gets
notified correctly...
Cheers
Jasmin
Hi,
when upgrading to kamailio 3.3 I have noticed, that in the database
structure new indexes are present (e.g. in presence module).
The problem is, that some of those indexes are too long for mysql, if
the DB charset is utf8 (mysql calculates several bytes per character):
"Specified key was too long; max key length is 1000 bytes".
This is a very well-known limitation in mysql:
http://bugs.mysql.com/bug.php?id=4541
... and I think we can not expect this behaviour to be changed in future
versions of mysql (at least that is what comments like "redesign your
table" or "table design is bad" indicate).
Not using utf8 at all is (in my opinion) not really a solution.
That means, that mysql-support for the DB structure is somewhat limited...?
What about MariaDB as an alternative?
Cheers
Jasmin
Module: sip-router
Branch: pd/outbound
Commit: 6b4d87a4321f8edefbf93b1323502d4bab965290
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=6b4d87a…
Author: Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>
Committer: Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>
Date: Thu Mar 14 14:19:31 2013 +0000
modules/registrar: Updated documentation for outbound related modparams
---
modules/registrar/README | 39 +++++++++++-----------
modules/registrar/doc/registrar_admin.xml | 51 +++++++++++++---------------
2 files changed, 43 insertions(+), 47 deletions(-)
diff --git a/modules/registrar/README b/modules/registrar/README
index f89b36d..afc7160 100644
--- a/modules/registrar/README
+++ b/modules/registrar/README
@@ -642,24 +642,23 @@ modparam("registrar", "gruu_enabled", 0)
3.24. outbound_mode (integer)
- If set to 0 then this module will accept REGISTER requests that do not
+ If set to 0 this module will accept REGISTER requests that do not
contain a Supported: header with the outbound options-tag. The 200 OK
response to REGISTER requests that this module generates will not
- contain Require: or Supported: headers with the outbound options tag.
+ contain Require: or Supported: headers with the outbound options-tag.
+ If the client has a Require: header with the outbound options tag the
+ REGISTER will be rejected with a 420 Bad Extension response.
- If set to 1 then this module will accept REGISTER requests that do not
- contain a Supported: header with the outbound options-tag. The 200 OK
- response to REGISTER requests that this module generates will contain a
- Supported: header with the outbound options tag.
-
- If set to 2 then this module will reject REGISTER requests that do not
- contain a Supported: header with the outbound options-tag. The 200 OK
- response to REGISTER requests that this module generates will contain
- Require: and Supported: headers with the outbound options tag.
+ If set to 1 this module will accept REGISTER requests that do not
+ contain a Supported: header with the outbound options-tag and REGISTER
+ requests that do contain a Supported: or Requires: header with the
+ outbound options-tag. When the client supports outbound the appropriate
+ RFC5626 procedures will be followed.
- Set this parameter to 2 if you are using SIP Outbound (RFC 5626) and
- want your Edge Proxy to insert a Flow-Timer: header into the 200 OK
- response to REGISTERs (as per RFC 5626 section 5.4).
+ If set to 2 this module will reject REGISTER requests that do not
+ contain a Supported: header with the outbound options-tag. When the
+ client supports outbound the appropriate RFC5626 procedures will be
+ followed.
Default value is 0.
@@ -675,17 +674,17 @@ modparam("registrar", "outbound_mode", 2)
If set to > 0 then this module will add a Flow-Timer: header containing
this value to 200 OK responses to REGISTER requests. This parameter may
- only be set to a value > 0 when outbound_mode is set to 2.
+ only be set to a value > 0 when outbound_mode is set to 1 or 2.
When set to a value > 0 this parameter should be set to slightly less
than the connection timeout value between the UAC and the network (this
corresponds to the core tcp_connection_lifetime option and websocket
keepalive_timeout modparam). This parameter is most useful when you
- have a single edge proxy/registrar. If you are using a separate SIP
- Outbound Edge Proxy you should consider leaving this parameter set to 0
- and adding the Flow-Timer: header on the Edge Proxy (as this allows you
- to keep all of the timer values for a specific flow in one
- configuration - that of the Edge Proxy).
+ have a single edge proxy/registrar or if you have an edge proxy that
+ cannot modify responses. If you are using a separate edge proxy you
+ should consider leaving this parameter set to 0 and adding the
+ Flow-Timer: header on the edge proxy as this allows you to keep all of
+ the timer values for a specific flow in one configuration.
Default value is 0.
diff --git a/modules/registrar/doc/registrar_admin.xml b/modules/registrar/doc/registrar_admin.xml
index ef8e78b..8b0609d 100644
--- a/modules/registrar/doc/registrar_admin.xml
+++ b/modules/registrar/doc/registrar_admin.xml
@@ -724,31 +724,27 @@ modparam("registrar", "gruu_enabled", 0)
<section>
<title><varname>outbound_mode</varname> (integer)</title>
<para>
- If set to 0 then this module will accept REGISTER requests
- that do not contain a Supported: header with the outbound
- options-tag. The 200 OK response to REGISTER requests that this
- module generates will not contain Require: or Supported: headers
- with the outbound options tag.
+ If set to 0 this module will accept REGISTER requests that do
+ not contain a Supported: header with the outbound options-tag.
+ The 200 OK response to REGISTER requests that this module
+ generates will not contain Require: or Supported: headers with
+ the outbound options-tag. If the client has a Require: header
+ with the outbound options tag the REGISTER will be rejected
+ with a 420 Bad Extension response.
</para>
<para>
- If set to 1 then this module will accept REGISTER requests
- that do not contain a Supported: header with the outbound
- options-tag. The 200 OK response to REGISTER requests that this
- module generates will contain a Supported: header with the
- outbound options tag.
+ If set to 1 this module will accept REGISTER requests that
+ do not contain a Supported: header with the outbound
+ options-tag and REGISTER requests that do contain a Supported:
+ or Requires: header with the outbound options-tag. When the
+ client supports outbound the appropriate RFC5626 procedures
+ will be followed.
</para>
<para>
- If set to 2 then this module will reject REGISTER requests
- that do not contain a Supported: header with the outbound
- options-tag. The 200 OK response to REGISTER requests that this
- module generates will contain Require: and Supported: headers
- with the outbound options tag.
- </para>
- <para>
- Set this parameter to 2 if you are using SIP Outbound (RFC
- 5626) and want your Edge Proxy to insert a Flow-Timer: header
- into the 200 OK response to REGISTERs (as per RFC 5626 section
- 5.4).
+ If set to 2 this module will reject REGISTER requests that
+ do not contain a Supported: header with the outbound
+ options-tag. When the client supports outbound the appropriate
+ RFC5626 procedures will be followed.
</para>
<para>
<emphasis>
@@ -775,7 +771,7 @@ modparam("registrar", "outbound_mode", 2)
If set to > 0 then this module will add a Flow-Timer: header
containing this value to 200 OK responses to REGISTER requests.
This parameter may only be set to a value > 0 when
- <emphasis>outbound_mode</emphasis> is set to 2.
+ <emphasis>outbound_mode</emphasis> is set to 1 or 2.
</para>
<para>
When set to a value > 0 this parameter should be set to slightly
@@ -783,13 +779,14 @@ modparam("registrar", "outbound_mode", 2)
network (this corresponds to the core
<emphasis>tcp_connection_lifetime</emphasis> option and
<emphasis>websocket</emphasis>
- <emphasis>keepalive_timeout</emphasis> modparam). This parameter
- is most useful when you have a single edge proxy/registrar. If
- you are using a separate SIP Outbound Edge Proxy you should
+ <emphasis>keepalive_timeout</emphasis> modparam). This
+ parameter is most useful when you have a single edge
+ proxy/registrar or if you have an edge proxy that cannot modify
+ responses. If you are using a separate edge proxy you should
consider leaving this parameter set to 0 and adding the
- Flow-Timer: header on the Edge Proxy (as this allows you to
+ Flow-Timer: header on the edge proxy as this allows you to
keep all of the timer values for a specific flow in one
- configuration - that of the Edge Proxy).
+ configuration.
</para>
<para>
<emphasis>
Hi,
AFAIK, ICE is used to detect as many ways as possible to send media stream
to the other client. If it can't find, it will use TURN protocol to
determine media relay proxy.
How can ICE detect many ways? Can we benefit from ICE if we're in symmetric
NAT?
--
Khoa Pham
HCMC University of Science
Faculty of Information Technology
Hi,
Successfully compiled on Raspberry PI for armv6(hf).
root@rpi:/opt/kamailio# ./sbin/kamailio -V
version: kamailio 4.1.0-dev1 (arm6/linux) 7d46ff
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT-NOSMP, USE_DNS_CACHE, USE_DNS_FAILOVER,
USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 7d46ff
compiled on 22:47:35 Mar 13 2013 with gcc 4.6.3
A process of compilation is exactly the same, but need to add
CC_EXTRA_OPTS=-DNOSMP because SMP is not supported for arm atomic
operations.
You can add this remark in WIKI if you need.