Hi,
I am trying to use t_suspend()/t_continue() multiple times on the same
transaction. Calling t_suspend() more than once works, but the second
time I call t_continue() the transaction is killed and a 500 response is
sent. It is the "if (branch == t->nr_of_outgoings)" check from the code
fragment below (from t_suspend.c:t_continue()) that results in the
transaction being killed - you can see the debug/error line I added to
determine this in the fragment.
Is using t_suspend()/t_continue() multiple times something that should
work?
Thanks,
Peter
if (t->uas.status < 200) {
/* No final reply has been sent yet.
* Check whether or not there is any pending branch.
*/
for ( branch = 0;
branch < t->nr_of_outgoings;
branch++
) {
if ((t->uac[branch].request.buffer != NULL)
&& (t->uac[branch].last_received < 200)
)
break;
}
if (branch == t->nr_of_outgoings) {
/* There is not any open branch so there is
* no chance that a final response will be
received. */
ret = 0;
LM_ERR("branch == t->nr_of_outgoings\n");
goto kill_trans;
}
}
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
Hello,
I am studying the use case when a redis command returns an array
(REDIS_REPLY_ARRAY type in hiredis.h from
https://github.com/antirez/hiredis )
Function pv_get_redisc in kamailio/modules/ndb_redis/ndb_redis_mod.c :
365 returns a pv_value_t structure and currently only deals with
REDIS_REPLY_STRING
and REDIS_REPLY_INTEGER cases.
It seems looking at pvar.h that pv_value_t structure does not deal with
arrays. Is that correct? So returning an array is not an option...
Then a better aproach could be changing pv_parse_redisc_name function:
right now from README in ndb_redis:
after executing redis_cmd("srvN", "SET foo bar", "r"); I could get
$redis(r->type) and $redis(r->value)
it could be a good idea to add options like: $redis(r->size) and
$redis(r->value[Number]) when changing pv_parse_redisk_name function.
Do you think of that as a good approach?
Thanks in advance!
Vicente.
Module: sip-router
Branch: master
Commit: 201fc2d600e48fbb717531c79013c1b971f82d76
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=201fc2d…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: Tue Mar 27 14:38:57 2012 +0200
db_cluster: new module for generic database clustering
- the module allow to group several DB connections and perform commands
over them, based on policies such as round robin, serial try or
parallel execution
- any kind of db connection can make part from a cluster
- example use case: write in parallel to two databases and do round
robin read from them
- the module is a middle layer between modules and databases, reusing
existing db connectors. A module that wants to use such cluster, just
have to set the db_url to "cluster://clusterid"
- the module allow definition of multiple clusters
- see README for more details
- todo: enable/disable connections at runtime and via rpc
---
modules_k/db_cluster/Makefile | 15 +
modules_k/db_cluster/README | 162 +++++++++
modules_k/db_cluster/db_cluster_mod.c | 112 ++++++
modules_k/db_cluster/dbcl_api.c | 437 ++++++++++++++++++++++
modules_k/db_cluster/dbcl_api.h | 142 ++++++++
modules_k/db_cluster/dbcl_data.c | 479 +++++++++++++++++++++++++
modules_k/db_cluster/dbcl_data.h | 89 +++++
modules_k/db_cluster/doc/Makefile | 4 +
modules_k/db_cluster/doc/db_cluster.xml | 37 ++
modules_k/db_cluster/doc/db_cluster_admin.xml | 167 +++++++++
10 files changed, 1644 insertions(+), 0 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=201…
Hi,
RFC 3856 section 6.10 states: "A PA SHOULD NOT generate notifications for
a single presentity at a rate of more than once every five seconds."
I would like to add this to the presence module (making the rate
configurable).
I have an idea as to how I would like to do it:
- Add a last notified time-stamp field to each presentity
- Add a updated since last notified flag field to each presentity
- Add a notify required flag field to each active_watcher
- When a presentity is updated the last notified time-stamp is checked.
If the time is far enough in the past the notifies are sent and the
time-stamp is updated. If enough time has not passed the updated since
flag is set for the presentity and the notify required flag is set for all
active_watchers of that presentity.
- When a presentity is subscribed to (this includes re-subscribes) the
last notified time-stamp is checked. If the time is far enough in the
past the (single) notify is sent and the time-stamp is updated. If enough
time has not passed the updated since flag is set for the presentity and
the notify required flag is set for this active_watcher record.
- A timer (the minimum time between subscribes - default 5 seconds) is
run. On expiry a query is done on the presentity table for presentities
that have been updated _AND_ the last notified time is more than the
minimum time ago. For each of these presentities, a query is done on the
active_watchers for watchers of that presentity that have the notify
required flag set. Notifies containing the presentities are then sent to
the watchers waiting on them.
This should ensure that no presentity notifies more than it should, while
ensuring that all changes are (eventually) sent out, and all subscribes
result in a notify (eventually) being sent. Eventually being typically
within 5 seconds and in under 10 seconds in the worst case (assuming the
default setting of 5 seconds).
Can anyone see any problems with this?
Are there any objections to me implementing this?
In theory running a (5 second) timer could make presence "lumpy" in the
same way RLS is (see my previous email). However, if this proves to be
the case I believe the same mechanism I have proposed for RLS can be used
here.
Regards,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task is now closed:
FS#209 - Dialog module loses profile state on proxy restart
User who did this - Daniel-Constantin Mierla (miconda)
Reason for closing: Implemented
Additional comments about closing: This was implemented already. Closing here, further discussions can be done on mailing lists.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=209
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task is now closed:
FS#189 - dlg_manage() after t_newtran() does not work
User who did this - Daniel-Constantin Mierla (miconda)
Reason for closing: Implemented
Additional comments about closing: This should be ok after the commit 7a8ad6740c244d48911f0216f6baac4804ea2f3b (Feb 25, master branch). Reopen if still an issue.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=189
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Hi all,
I've been playing with the new mono api on the development version of
Kamailio. I'm having some problems with it, perhaps there's something
someone here knows that would help. If there's a better place to post
this question please guide me to the right direction.
I'm using CentOS 6.2, installed mono with yum, the mono version is 2.4.3.1.
I had problems compiling the app_mono module, I got errors like:
Package mono-2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `mono-2.pc'
to the PKG_CONFIG_PATH environment variable
No package 'mono-2' found
...
So I changed the makefile to the one below (replaced "mono-2" to
"mono" from the default). Then got it compiled and app_mono.so was
generated. I don't know much about makefiles but me guessing what to
do with it got the thing compiled.
#
#
include ../../Makefile.defs
auto_gen=
NAME=app_mono.so
BUILDER = $(shell which pkg-config)
ifeq ($(BUILDER),)
DEFS+=-D_REENTRANT -I/usr/include/mono
LIBS= -lmono -lm -lrt -ldl -lpthread
else
DEFS+= $(shell pkg-config --cflags mono)
LIBS = $(shell pkg-config --libs mono)
endif
DEFS+=-DOPENSER_MOD_INTERFACE
SERLIBPATH=../../lib
SER_LIBS+=$(SERLIBPATH)/kcore/kcore
include ../../Makefile.modules
Then I compiled Kamailio with the app_mono module included, during
compilation I got output like this:
[root@monotest kamailio]# make all
CC (gcc) [M app_mono.so] app_mono_api.o
app_mono_api.c: In function âsr_mono_logâ:
app_mono_api.c:318: warning: implicit declaration of function âmono_freeâ
CC (gcc) [M app_mono.so] app_mono_mod.o
make[2]: `libkcore.so.1.0' is up to date.
LD (gcc) [M app_mono.so] app_mono.so
...
I added my params on the config:
loadmodule "app_mono.so"
...
modparam("app_mono", "load", "/usr/local/etc/kamailio/mono/MonoTest1.exe")
Everything compiled though and I did not notice any errors. However,
there must be something wrong with either my environment, mono
version, compiling something or something else, command kamailio -c
gives output with errors (note the warning before and the error below
about mono_free):
[root@monotest kamailio]# kamailio -c
loading modules under
/usr/local/lib/kamailio/modules_k/:/usr/local/lib/kamailio/modules/
0(26471) ERROR: <core> [sr_module.c:572]: ERROR: load_module: could
not open module
</usr/local/lib/kamailio/modules/app_mono.so>:
/usr/local/lib/kamailio/modules/app_mono.so: undefined symbol:
mono_free
0(26471) : <core> [cfg.y:3565]: parse error in config file
/usr/local/etc/kamailio/modules.cfg, line 90, column
12-24: failed to load module
0(26471) ERROR: <core> [modparam.c:162]: set_mod_param_regex: No
module matching <app_mono> found
0(26471) : <core> [cfg.y:3568]: parse error in config file
/usr/local/etc/kamailio/modules.cfg, line 281,
column 74: Can't set module parameter
0(26471) ERROR: <core> [cfg.y:3429]: cfg. parser: failed to find
command mono_run
Any ideas on what's the problem?
I'll try the same on Ubuntu to compare but any suggestions and advice
would be appreciated!
cheers,
Pirjo Ahvenainen