THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#191 - bad sotket after re-register in location table
User who did this - David Kovarik (kovik)
----------
kamailio -V
version: kamailio 3.2.1 (x86_64/linux) 918035-dirty
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, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, 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: 918035 -dirty
compiled on 14:33:55 Dec 12 2011 with gcc 4.4.5
root@serZ2:/# uname -a
Linux serZ2 2.6.32-5-vserver-amd64 #1 SMP Tue Jun 14 11:50:10 UTC 2011 x86_64 GNU/Linux
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=191#comment465
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 has a new comment added:
FS#191 - bad sotket after re-register in location table
User who did this - David Kovarik (kovik)
----------
it is random good/bad, my phone is reregister after 60s for test.
+--------------------------+----------------------+--------------------------------------------------+---------------------+-------------------------------+
| received | socket | user_agent | expires | contact |
+--------------------------+----------------------+--------------------------------------------------+---------------------+-------------------------------+
| sip:85.135.106.202:55062 | udp:81.31.45.57 060 | Linksys/SPA941-5.1.8 | 2011-12-15 00:23:17 | sip:413205@192.168.2.103:5061 |
| sip:85.135.106.202:4078 | udp:81.31.45.57:5060 | Well T20 hw7.0.0.54 fw9.60.9.5 00:15:65:15:ae:b2 | 2011-12-15 00:23:47 | sip:300169@192.168.2.101:5062 |
+--------------------------+----------------------+--------------------------------------------------+---------------------+-------------------------------+
----------
One or more files have been attached.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=191#comment464
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.
Module: sip-router
Branch: master
Commit: 2f38f2c316bc3c0410ac1bd61747ca8c69480937
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=2f38f2c…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: Wed Dec 14 23:18:36 2011 +0100
core/timer: added support for basic mili-second timers
- renamed second-based timer functions from dummy to basic
---
timer.h | 2 ++
timer_proc.c | 51 +++++++++++++++++++++++++++++++++++++++++++++------
timer_proc.h | 35 +++++++++++++++++++++++++++++------
3 files changed, 76 insertions(+), 12 deletions(-)
diff --git a/timer.h b/timer.h
index 4adcc8e..d2ba3dd 100644
--- a/timer.h
+++ b/timer.h
@@ -76,6 +76,8 @@ typedef void (timer_function)(unsigned int ticks, void* param);
timer_ticks.h (.e.g TICKS_TO_S(tick) to convert to s or ms )*/
#define TIMER_TICK 1 /* 1 s, kept for compatibility */
+/*function prototype to execute on mili-second based basic timers */
+typedef void (utimer_function)(unsigned int uticks, void* param);
struct timer_ln; /* forward decl */
/* new
diff --git a/timer_proc.c b/timer_proc.c
index 36e4836..c354fbd 100644
--- a/timer_proc.c
+++ b/timer_proc.c
@@ -38,17 +38,18 @@
#include "timer_proc.h"
#include "cfg/cfg_struct.h"
#include "pt.h"
+#include "ut.h"
#include "mem/shm_mem.h"
#include <unistd.h>
/**
- * \brief update internal counters for running new dummy timers
- * @param timers number of dummy timer processes
+ * \brief update internal counters for running new basic sec. timers
+ * @param timers number of basic timer processes
* @return 0 on success; -1 on error
*/
-int register_dummy_timers(int timers)
+int register_basic_timers(int timers)
{
if(register_procs(timers)<0)
return -1;
@@ -61,9 +62,9 @@ int register_dummy_timers(int timers)
*
* Forks a very basic periodic timer process, that just sleep()s for
* the specified interval and then calls the timer function.
- * The new "dummy timer" process execution start immediately, the sleep()
+ * The new "basic timer" process execution start immediately, the sleep()
* is called first (so the first call to the timer function will happen
- * \<interval\> seconds after the call to fork_dummy_timer)
+ * \<interval\> seconds after the call to fork_basic_timer)
* @param child_id @see fork_process()
* @param desc @see fork_process()
* @param make_sock @see fork_process()
@@ -73,7 +74,7 @@ int register_dummy_timers(int timers)
* @return pid of the new process on success, -1 on error
* (doesn't return anything in the child process)
*/
-int fork_dummy_timer(int child_id, char* desc, int make_sock,
+int fork_basic_timer(int child_id, char* desc, int make_sock,
timer_function* f, void* param, int interval)
{
int pid;
@@ -94,6 +95,44 @@ int fork_dummy_timer(int child_id, char* desc, int make_sock,
return pid;
}
+/**
+ * \brief Forks a separate simple milisecond-sleep() periodic timer
+ *
+ * Forks a very basic periodic timer process, that just ms-sleep()s for
+ * the specified interval and then calls the timer function.
+ * The new "basic timer" process execution start immediately, the ms-sleep()
+ * is called first (so the first call to the timer function will happen
+ * \<interval\> seconds after the call to fork_basic_utimer)
+ * @param child_id @see fork_process()
+ * @param desc @see fork_process()
+ * @param make_sock @see fork_process()
+ * @param f timer function/callback
+ * @param param parameter passed to the timer function
+ * @param uinterval interval in mili-seconds.
+ * @return pid of the new process on success, -1 on error
+ * (doesn't return anything in the child process)
+ */
+int fork_basic_utimer(int child_id, char* desc, int make_sock,
+ utimer_function* f, void* param, int uinterval)
+{
+ int pid;
+ ticks_t ts;
+
+ pid=fork_process(child_id, desc, make_sock);
+ if (pid<0) return -1;
+ if (pid==0){
+ /* child */
+ if (cfg_child_init()) return -1;
+ for(;;){
+ sleep_us(uinterval);
+ cfg_update();
+ ts = get_ticks_raw();
+ f(TICKS_TO_MS(ts), param); /* ticks in mili-seconds */
+ }
+ }
+ /* parent */
+ return pid;
+}
/**
diff --git a/timer_proc.h b/timer_proc.h
index b6c9a66..e6faa7c 100644
--- a/timer_proc.h
+++ b/timer_proc.h
@@ -35,21 +35,24 @@
#include "local_timer.h"
/**
- * \brief update internal counters for running new dummy timers
- * @param timers number of dummy timer processes
+ * \brief update internal counters for running new basic sec. timers
+ * @param timers number of basic timer processes
* @return 0 on success; -1 on error
*/
-int register_dummy_timers(int timers);
+int register_basic_timers(int timers);
+#define register_dummy_timers register_basic_timers
+
+#define register_basic_utimers register_basic_utimers
/**
* \brief Forks a separate simple sleep() periodic timer
*
* Forks a very basic periodic timer process, that just sleep()s for
* the specified interval and then calls the timer function.
- * The new "dummy timer" process execution start immediately, the sleep()
+ * The new "basic timer" process execution start immediately, the sleep()
* is called first (so the first call to the timer function will happen
- * \<interval\> seconds after the call to fork_dummy_timer)
+ * \<interval\> seconds after the call to fork_basic_timer)
* @param child_id @see fork_process()
* @param desc @see fork_process()
* @param make_sock @see fork_process()
@@ -59,11 +62,31 @@ int register_dummy_timers(int timers);
* @return pid of the new process on success, -1 on error
* (doesn't return anything in the child process)
*/
-int fork_dummy_timer(int child_id, char* desc, int make_sock,
+int fork_basic_timer(int child_id, char* desc, int make_sock,
timer_function* f, void* param, int interval);
+#define fork_dummy_timer fork_basic_timer
/**
+ * \brief Forks a separate simple milisecond-sleep() periodic timer
+ *
+ * Forks a very basic periodic timer process, that just ms-sleep()s for
+ * the specified interval and then calls the timer function.
+ * The new "basic timer" process execution start immediately, the ms-sleep()
+ * is called first (so the first call to the timer function will happen
+ * \<interval\> seconds after the call to fork_basic_utimer)
+ * @param child_id @see fork_process()
+ * @param desc @see fork_process()
+ * @param make_sock @see fork_process()
+ * @param f timer function/callback
+ * @param param parameter passed to the timer function
+ * @param uinterval interval in mili-seconds.
+ * @return pid of the new process on success, -1 on error
+ * (doesn't return anything in the child process)
+ */
+int fork_basic_utimer(int child_id, char* desc, int make_sock,
+ timer_function* f, void* param, int uinterval);
+/**
* \brief Forks a timer process based on the local timer
*
* Forks a separate timer process running a local_timer.h type of timer
Hi!
I stumbled upon http://jitsi.org/index.php/GSOC2011/KamailioJingle
What is the current status? Has the project advanced?
Jingle support would make my life way easier.
If time / alternative summer job permits, all I care for is the functionality.
Doing that while google pays would be more like sweet bonus.
Thanks for answer.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#191 - bad sotket after re-register in location table
User who did this - Daniel-Constantin Mierla (miconda)
----------
Can you provide the log messages with debug=3?
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=191#comment463
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,
Siremis v3.2.0 is out - the web management interface for Kamailio and
SER v3.2.x series.
Besides updates to existing views to match the database schema in
Kamailio v3.2.x (such as lcr, dialog or siptrace), there are many new
features. Among most important:
- SQL-based CDR rating engine for billing purposes, with views to manage
the rating rules
- charts and table summaries to reflect the activity of accounting records
- new views to manage records for remote registrations, mtree and global
black list
- command line tools to add new database table views in a step-by-step
wizard fashion
- selection of usernames and domains for many views can be done by a
select box or picker form with values from subscriber or domain tables
More details can be find in the announcement of the release on the web site:
* http://asipto.com/u/4t
or in the ChangeLog inside the tarball.
Siremis can be downloaded from:
* http://asipto.com/u/sd
Alternative download site, along with the GIT repository for Siremis, is
offered at sourceforge.net project:
* http://sourceforge.net/projects/siremis/
Regards,
Ramona
should have sent this to list – sorry
From: Paul Pankhurst
Sent: Tuesday, December 13, 2011 12:03 PM
To: miconda(a)gmail.com
Subject: Re: [sr-dev] db_fetch_next problem with Postgres?
Hi Daniel,
I have a bit more information...
the outline pseudo code for what I am doing looks like this (removing non relevant stuff)
db_fetch_query( xcap_db )
do
{
query( another_2nd_db )
} while ( db_fetch_next( xcap_db) )
it is the query to the second database that breaks everything...if I remove it the problem goes away and db_fetch_next works as expected.
The access to the 2nd database uses completely different db_func_t and db1_cont_t structures to the xcap_db
I’ll try running it with extra debug shortly to see if I can see what’s happening
Paul
From: Daniel-Constantin Mierla
Sent: Tuesday, December 13, 2011 11:10 AM
To: Development mailing list of the sip-router project
Cc: Paul Pankhurst
Subject: Re: [sr-dev] db_fetch_next problem with Postgres?
Hello,
On 12/13/11 11:40 AM, Paul Pankhurst wrote:
I am having problems with the db_fetch_next routine and Postgres.
I can’t see any problem with my code that calls it, and as far as I can tell the problem appears to be in the db_postgres_fetch_result routine.
On the first invocation of db_postgres_fetch_result it allocates a result structure and gives me the first 5 rows of the 198 that match my query after calling db_postgres_convert_rows.
On the 2nd invocation it fails to retrieve the next 5 rows because CON_RESULT(_con) is NULL !
Anyone got any suggestions?
can you doublecheck and see if you don't call free_result() before fetching the next rows? If you run with debug=3, if there is a free_result, you should see the log message from:
LM_DBG("PQclear(%p) result set\n", CON_RESULT(_con))
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.comhttp://linkedin.com/in/miconda -- http://twitter.com/miconda