I've got a strange issue with the latest kamailio. I also had this
problem with kamailio 3.0.3 downloaded from the webpage.
I can start kamailio, but after a while (sometimes within one minuten,
sometimes after an hour),
I get the following log errors:
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [db.c:387]:
invalid type (3) or nul (0) version columns for trusted
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [db.c:405]:
querying version for table …
[View More]trusted
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: permissions
[trusted.c:249]: error during table version check.
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core>
[sr_module.c:832]: init_mod_child(): Error while initializing module
permissions (//lib/kamailio/modules_k/permissions.so)
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core> [pt.c:481]:
ERROR: fork_tcp_process(): init_child failed for process 10, pid 26621,
"tcp receiver child=0"
Oct 12 15:46:24 sp01 /sbin/kamailio[26621]: ERROR: <core>
[tcp_main.c:4811]: ERROR: tcp_main: fork failed: Success
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core> [pass_fd.c:103]:
ERROR: recv_all: 1st recv on 21 failed: Connection reset by peer
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core> [tcp_main.c:3323]:
ERROR: handle_tcp_child: read from tcp child 0 (pid 26621, no 10)
Connection reset by peer [104]
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: : <core> [pass_fd.c:293]:
ERROR: receive_fd: EOF on 19
Oct 12 15:46:24 sp01 /sbin/kamailio[26611]: ALERT: <core> [main.c:738]:
child process 26621 exited normally, status=255
Oct 12 15:46:24 sp01 /sbin/kamailio[26611]: INFO: <core> [main.c:756]:
INFO: terminating due to SIGCHLD
Oct 12 15:46:24 sp01 /sbin/kamailio[26625]: INFO: <core> [main.c:807]:
INFO: signal 15 received
Looking at the error message, it thinks that the column type of
table_version in the table version is a string (type 3), and it should
be an int (type 1).
But in the database it really is an int.
When I run kamailio with debugging on level 5, I see that it's trying to
run the "select table_version from version where table_name='trusted'"
several times when kamailio starts (for every child thread).
And then minutes, of even an hour later, it suddenly continues with that
check, but based on a database response from another query.
This is the "select password from subscriber ....etc...".
And that column is indeed an string.
I'm using PostgreSQL 8.4 as server,
but maybe someone has seen this before, or now where I have to start
looking?
I first saw it yesterday when started to use the permissions module.
I only see this with the trusted table,
And always it uses the "select password from subscriber ... " response
when giving this error.
So is this an error in the permissions module / trusted.c file?
or something in auth_db that's not freeing the response correctly?
Strange thing is, that is sometimes happens very quick, and sometimes it
can take an half hour or hour.
I can mail the full log if anybody is interested and thinks he/she can
help me.
With kind regards,
Robert Verspuy
--
*Exa-Omicron*
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl
[View Less]
i noticed that if i add ;alias param to contact header that does not
surround its contact uri in <>s like this:
Contact: sip:foo@bar;alias=value
then some sip entities interpret ;alias as header param rather than uri
param.
so i went and added <>s if they are not present resulting to this:
Contact: <sip:foo@bar;alias=value>
i have tried to figure out from rfc3261 what kind of param ;alias is in
the first example, but have not found the answer. looks like it is
…
[View More]unspecified in rfc3261.
any comments on this?
-- juha
[View Less]
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#105 - $Ts returns wrong timestamp
User who did this - Alex Hermann (axlh)
----------
Ok, that explains the first case in technical terms. Logically i still find it strange the $Ts in failure_route is not the same as the one in request_route because it is supposed to handle the same message/request.
The 2nd case of the timestamp being from an entirely different message is a bit more worrying. Besides …
[View More]the annoyance of the wrong timestamp, I fear the timestamp may not be the only variable not correctly being cleared/initialized when a fake reply is created. I still haven't dared to look into tm though, so can't say for sure.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=105#comment140
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.
[View Less]