THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#427 - kamailio sometimes crash when handling failure events
User who did this - Pawel Sternal (Sternik)
----------
only prints log messages. The crash appears under higher load. I suppose it will happen Monday morning.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=427#comment1457
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#429 - dialplan: allow match/subst rules with variables
User who did this - Juha Heinanen (jh)
----------
i asked on the mailing list, if this patch affects performance if pvs are not in use. it must not do so.
----------
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=429#comment1456
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#427 - kamailio sometimes crash when handling failure events
User who did this - Daniel-Constantin Mierla (miconda)
----------
That ref from 0 to 1 is ok. Did it crash in this case? Or just the log messages, going on afterwards.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=427#comment1455
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#429 - dialplan: allow match/subst rules with variables
User who did this - Daniel-Constantin Mierla (miconda)
----------
Can you detail a bit the approach, what happens where there are pvs? The second patch is quite long, so just understanding from source code might be tough. I see some hash table, new structure, a.s.o.
----------
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=429#comment1454
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.
I'm running a version of Kamailio from commit
a7dc504075d3b5c74c6af6a3216338a0d604d1d8 (18 Feb), so I'm not sure if
this has been fixed.
Anyway, I was testing a TCP client and the dialog went stale and was
timed out by the dialog module using a local BYE. One of the endpoints
responded to the BYE with a 481 message, and Kamailio appears to have
crashed on this.
(gdb) where
#0 0xb717c432 in t_reply_matching (p_msg=0xb7419990, p_branch=0xbfe26e98)
at t_lookup.c:987
#1 0xb717f52a in t_check_msg (p_msg=0xb7419990, param_branch=0xbfe26e98)
at t_lookup.c:1129
#2 0xb71800e4 in t_check (p_msg=0xb7419990, param_branch=0xbfe26e98)
at t_lookup.c:1171
#3 0xb71aa189 in reply_received (p_msg=0xb7419990) at t_reply.c:2187
#4 0x0809fd8d in do_forward_reply (msg=0xb7419990, mode=-1289507656)
at forward.c:777
#5 0x080eafb5 in receive_msg (
buf=0x82d6800 "SIP/2.0 481 Unknown Dialog\r\nVia: SIP/2.0/UDP
208.52.173.18;branch=z9hG4bK931e.95a61f6", '0' <repeats 25 times>,
".0\r\nTo:
<sip:+14046822836@208.52.173.18;user=phone>;tag=SDjfglb99-ac3f4687+1+f2d10012+a5eff02c\r\nFrom:
<sip:+1404xxxxxxx@yyyyyyyyyy.net;user=phone>;tag=acd791cf4\r\nCSeq:
24980 BYE\r\nCall-ID: 3f7eb5b5-57ca-4de0-80eb-4d8f28ceb7ca\r\n\r\n",
len=337,
rcv_info=<value optimized out>) at receive.c:273
#6 0x08184cd8 in udp_rcv_loop () at udp_server.c:536
#7 0x080b0f10 in main_loop () at main.c:1617
#8 0x080b4234 in main (argc=11, argv=0xbfe27374) at main.c:2533
The actual crash is here:
(gdb) frame 0
#0 0xb717c432 in t_reply_matching (p_msg=0xb7419990, p_branch=0xbfe26e98)
at t_lookup.c:987
987 (p_msg->callid->body.len !=
p_cell->uas.request->callid->body.len ||
And, it would seem that the cause is that is p_cell->uas.request == NULL:
(gdb) print p_cell->uas.request
$1 = (struct sip_msg *) 0x0
This is all the information I have, and unfortunately I don't think I
can reproduce this crash.
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#427 - kamailio sometimes crash when handling failure events
User who did this - Pawel Sternal (Sternik)
----------
Hmm, for this log
<code>
May 16 20:57:32 node03 /usr/sbin/kamailio[30505]: ERROR: dialog [dlg_hash.c:775]: link_dlg(): info - dlg 0xa4d6ebbc ref from 0 with 1
</code>
I found a critical error for dlg 0xa4d6ebbc:
<code>
May 16 20:57:41 node03 /usr/sbin/kamailio[30483]: CRITICAL: dialog [dlg_hash.c:842]: log_next_state_dlg(): bogus event 6 in state 2 for dlg 0xa4d6ebbc [160:4911] with clid '6ab6692d4d032e9a25ee1f760a71e4ea(a)sip.siptrunking.pl' and tags 'as380d5df2' ''
</code>
it occurred while processing ack packet
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=427#comment1453
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#427 - kamailio sometimes crash when handling failure events
User who did this - Pawel Sternal (Sternik)
----------
I use two times event_route. First:
<code>
event_route[cnxcc:call-shutdown]{
xlog("L_NOTICE", "LOG:$ci (route CCF-Call-Shutdown) Message buffer: $mb\n");
avp_db_query("select o_from,o_to,r_from,r_to,ftag,aba_contact,abb_contact,icid,mcid,icid_var from dialog_data where callid='$ci'",
"$avp(o_from);$avp(o_to);$avp(r_from);$avp(r_to);$avp(ftag);$avp(aba_contact);$avp(abb_contact);$avp(9051);$avp(9050);$avp(icid_next)");
# End RTP session
xlog("L_INFO", "LOG (route GET_RTPPROXY_SET) did = $avp(did)\n");
# if did is empty, trying to get from db
if($avp(did)==$null){
avp_db_query("select did from dialog_data where callid='$ci'","$avp(did)");
}
xlog("L_INFO", "LOG (route GET_RTPPROXY_SET) did = $avp(did)\n");
if($avp(did)==1){
set_rtp_proxy_set("1");
}else{
set_rtp_proxy_set("2");
}
rtpproxy_destroy();
# Saving $TS
avp_db_query("update dialog_data set last_cc_event_timestamp='$TS' where callid='$ci'");
# Sending ACC Stop
$avp(acr_type)="Stop";
acc_rad_request("200 OK");
acc_log_request("200 OK");
}
</code>
And second:
<code>
event_route[tm:local-request]{
xlog("L_NOTICE", "LOG:$ci (event route LOCAL-REQUEST) Method: $rm\n");
if(is_method("OPTIONS")) route(LOCAL_REQUEST_OPTIONS);
#!ifdef PUA_DIALOG_INFO
else if(is_method("PUBLISH")) route(LOCAL_REQUEST_PUBLISH);
#!endif
else {
xlog("L_NOTICE", "LOG:$ci (route tm:local-request) Method: $rm\n");
}
}
route[LOCAL_REQUEST_OPTIONS]{
if($hdr(X-CRX-Info)=="AliveTest"){t_on_reply("ALIVE_TEST");}
}
</code>
About route(LOCAL_REQUEST_PUBLISH) I'll send you privately if you don't mind.
I applied this patch an upraded for nodes. And looks like it works:
<code>
May 16 20:49:52 node02 /usr/sbin/kamailio[23729]: ERROR: dialog [dlg_hash.c:775]: link_dlg(): info - dlg 0xa50299a4 ref from 0 with 1
May 16 20:49:58 node02 /usr/sbin/kamailio[23691]: ERROR: dialog [dlg_hash.c:775]: link_dlg(): info - dlg 0xa4dc9040 ref from 0 with 1
May 16 20:50:13 node02 /usr/sbin/kamailio[23735]: ERROR: dialog [dlg_hash.c:775]: link_dlg(): info - dlg 0xa4ed1c00 ref from 0 with 1
May 16 20:50:40 node02 /usr/sbin/kamailio[23729]: ERROR: dialog [dlg_hash.c:775]: link_dlg(): info - dlg 0xa5039480 ref from 0 with 1
May 16 20:51:36 node02 /usr/sbin/kamailio[23694]: ERROR: dialog [dlg_hash.c:775]: link_dlg(): info - dlg 0xa4dc9040 ref from 0 with 1
May 16 20:51:54 node02 /usr/sbin/kamailio[23733]: ERROR: dialog [dlg_hash.c:775]: link_dlg(): info - dlg 0xa50272d0 ref from 0 with 1
May 16 20:52:08 node02 /usr/sbin/kamailio[23688]: ERROR: dialog [dlg_hash.c:775]: link_dlg(): info - dlg 0xa5039480 ref from 0 with 1
May 16 20:52:15 node02 /usr/sbin/kamailio[23736]: ERROR: dialog [dlg_hash.c:775]: link_dlg(): info - dlg 0xa4dc9040 ref from 0 with 1
May 16 20:52:19 node02 /usr/sbin/kamailio[23699]: ERROR: dialog [dlg_hash.c:775]: link_dlg(): info - dlg 0xa5052464 ref from 0 with 1
</code>
today restart doesn't occurred :/
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=427#comment1452
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,
I've run into a situation where I want to throttle the number concurrent
calls proxied by Kamailio based upon the SIP Server through which they are
intended to go to the end point.
The network diagram is somewhat like -
UACs (n) -------> Kamailio (on public IP) ------ > SIP Servers (m) (on
public IPs) ------------> UACs or TerminationsGateways
So basically, n UACs registered to m SIP Servers via Kamailio (working as
a proxy). And now I want to put the limitation on all the concurrent calls
going to different SIP Servers.
Say for an example, only 100 concurrent calls could be setup for SIP Server
'a' , 50 for SIP Server 'b' so on and so forth.
I tried checking the different modules but could not find any clue as to
how to achieve this through configuration.
Now, I can try tweaking a tad of the code to send '403 Forbidden' message
from receive.c (although I am not sure whether this is the correct place to
do something like this..)
I'd be grateful if somebody can throw light on how to achieve this.
Please can someone help on this.
--
Warm Regds.
MathuRahul
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#427 - kamailio sometimes crash when handling failure events
User who did this - Daniel-Constantin Mierla (miconda)
----------
I suspect that some event_route or rtimer route execution is messing the reference count for dialog, because of pre-post-script callbacks. Can you apply the attached patch that logs when the reference is incremented from zero. It will print once for creating the dialog, but I want to see if its getting again to 0 and then incremented.
Also, can you list all event_route blocks you are using? Or alternative, share the config file somehow.
----------
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=427#comment1451
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 - sdp_keep_codecs_by_name also removes dtmf/telephone-event
Task Type - Bug Report
Category - Modules kamailio
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Low
Priority - Normal
Reported Version - 4.1
Due in Version - Undecided
Due Date - Undecided
Details - As the subject says. When running for example sdp_keep_codecs_by_name("ALAW"), it also removes dtmf from sdp.
I do not think this should be the correct behaviour?
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=428
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.