THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task is now closed:
FS#458 - Do not fork command line option
User who did this - Daniel-Constantin Mierla (miconda)
Reason for closing: Fixed
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=458
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#458 - Do not fork command line option
User who did this - Daniel-Constantin Mierla (miconda)
----------
Help content was fixed to reflect current behaviour and relation to command line parameters:
<code>
-D - do not fork (almost) anyway (run in foreground, doesn't fork into daemon mode);
-DD - do not daemonize creator (main process is not daemonized);
-DDD - daemonize (default)
</code>
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=458#comment1602
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#464 - Memory leak in tm module?
User who did this - Daniel-Constantin Mierla (miconda)
Reason for closing: Fixed
Additional comments about closing: Fixed some time ago -- reopen if you think is another issue than one mentioned with the fix in the comment.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=464
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#464 - Memory leak in tm module?
User who did this - Daniel-Constantin Mierla (miconda)
----------
This looks like fixed by commit d921b452687a31ab49b7c5c4420c0c6134916140
You have to upgrade to latest 4.1.x -- it is included there. There is no change to config file or database from 4.1.1 to newer 4.1.x, simply deploy the newer version and restart kamailio.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=464#comment1601
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#462 - force_send_socket in event route tm:local-request
User who did this - Kristian Høgh (kfhdk)
----------
The attached patch works for me.
In tm:local-request I call set_advertised_address() and force_send_socket().
I only change the IP address, and haven't testet change in proto, port...
----------
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=462#comment1600
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.
A new Flyspray task has been opened. Details are below.
User who did this - Morten Tryfoss (mtryfoss)
Attached to Project - sip-router
Summary - Memory leak in tm module?
Task Type - Bug Report
Category - tm
Status - Unconfirmed
Assigned To -
Operating System - Linux
Severity - Medium
Priority - Normal
Reported Version - 4.1
Due in Version - Undecided
Due Date - Undecided
Details - We have got a production system with a slow but steady increase of shared memory use when routing calls.
The kamailio version is 4.1.1.
I'm able to reproduce this in a lab. The call scenario is like this:
Call from asterisk using udp to kamailio, which looks up the registered user (tested both udp and tls) and forwards using t_relay().
The call is then either answered or canceled.
When I stop kamailio I get two of those lines for each call that has been routed:
Aug 25 15:23:55 sip1stage /usr/sbin/kamailio[14285]: qm_status: 8372. N address=0x7fc21369f348 frag=0x7fc21369f318 size=56 used=1
Aug 25 15:23:55 sip1stage /usr/sbin/kamailio[14285]: qm_status: alloc'd from tm: t_fwd.c: prepare_new_uac(574)
Aug 25 15:23:55 sip1stage /usr/sbin/kamailio[14285]: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed
Aug 25 15:23:55 sip1stage /usr/sbin/kamailio[14285]: qm_status: 8373. N address=0x7fc21369f3e0 frag=0x7fc21369f3b0 size=24 used=1
Aug 25 15:23:55 sip1stage /usr/sbin/kamailio[14285]: qm_status: alloc'd from tm: t_fwd.c: prepare_new_uac(589)
Aug 25 15:23:55 sip1stage /usr/sbin/kamailio[14285]: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed
When the call is initiated, two of these lines appear in the log:
Aug 25 15:23:40 sip1stage /usr/sbin/kamailio[14286]: <core> [mem/q_malloc.c:369]: qm_malloc(): qm_malloc(0x7fc2132db000, 21) called from tm: t_fwd.c: prepare_new_uac(574)
Aug 25 15:23:40 sip1stage /usr/sbin/kamailio[14286]: <core> [mem/q_malloc.c:415]: qm_malloc(): qm_malloc(0x7fc2132db000, 24) returns address 0x7fc21369f348 frag. 0x7fc21369f318 (size=56) on 1 -th hit
Aug 25 15:23:40 sip1stage /usr/sbin/kamailio[14286]: <core> [mem/q_malloc.c:369]: qm_malloc(): qm_malloc(0x7fc2132db000, 20) called from tm: t_fwd.c: prepare_new_uac(589)
Aug 25 15:23:40 sip1stage /usr/sbin/kamailio[14286]: <core> [mem/q_malloc.c:415]: qm_malloc(): qm_malloc(0x7fc2132db000, 24) returns address 0x7fc21369f3e0 frag. 0x7fc21369f3b0 (size=24) on 1 -th hit
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=464
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.
Hello. At first- I think header of my message doesn't explain my porblem
but I can not say about it with different terms)
So. I have construction Asterisk --> Kamailio --> Providers
My provisers registered with UAC modure and stored at UACREG table.
Problem scenario is:
I ring from asterisk to provider
Asterisk --> Kamailio --> Providers
Call from asterisk come to kamailio with
furi(Asterisk_clinet_local_number@asterisk)
turi(external_number@kamailio)
Then, to forward INVITE to provider that Needed I use some manipulations to
choose provider (it does not matter, it is only sql_queryes to some
tables), and then modify invite with this code:
#$var(prov) - my.provider.ip
#$var(trunk) - name_of_trunk
$rd=$var(prov);
$rp="5060";
$fU=$var(trunk);
$fd=$var(prov);
$td=$var(prov);
remove_hf("Contact");
append_hf("Contact:<$var(trunk)@my.kamailio.domain:5068>\n","Contact");
So -after this manipulation I have write packet, that goues to my provider.
Then Provier sends me 407 answer and packet goes to failure_route
if (t_check_status("401|407")){
xlog("L_INFO", "Reply from provider on failure: $rs");
if (uac_auth()){
#my query to get avp for uac
#modparam("uac","auth_realm_avp","$avp(s:realm)")
#modparam("uac","auth_username_avp","avp(s:uname)")
#modparam("uac","auth_password_avp","$avp(s:passwd))")
sql_pvquery("ca","select auth_username, auth_password, realm from uacreg
where auth_username='$fU'","$var(uname), $var(passwd), $var(realm)");
xlog("L_INFO", "username=$var(uname),
password=$var(passwd), realm=$var(realm) for {$fU}");
pv_printf("$avp(s:uname)","$var(uname)");
pv_printf("$avp(s:passwd)","$var(passwd)");
pv_printf("$avp(s:realm)","$var(realm)");
xlog("L_INFO", "UAC_AUTH(): $rs");
append_branch();
t_relay();
}
}
if (t_is_canceled()) {
exit;
}
So After changes Before Provider answer 407 my $fU = name_of_trunk, but at
failure route my fU is Asterisk_clinet_local_number and it so strange
because I see this packet at TCPDUMP and it have trunkname at fU
Because of It I can not take from table needed vars for auth and avp`s Have
0.
So packet for Auth (407) goes to Asterisk (with trunkname!!!! at fU), but t
must stops at kamailio and must be ralayed to provider.
So this my problem- I can not understand: Why fU at reply 407 have old
parameters?