Hi,
I have a somewhat unusual log entry after some calls:
Sep 3 09:12:23 kamgw01 /usr/local/sbin/kamailio[542]: WARNING: tm
[t_lookup.c:1551]: WARNING: script writer didn't release transaction
These calls fail in that they are processed instantly, but no time is
ever given to receive a response from the upstream gateway. For
instance, the above call's initial INVITE was received at 09:12:23, a
final request URI was resolved, and then this message, all in < 1
second. Trace on upstream gateway shows that the initial request was
never received from Kamailio.
There is one additional aspect to how these calls are being processed
in script that almost certainly has a bearing on this, though I don't
know what it is:
They are handled through a gateway route route called
route[OUTBOUND-ROUTE-TRY] that is, under normal circumstances
reflecting its name, initially called from the request route, and
subsequently from a failure route meant to advance it.
Normal operation mode is like this:
route {
...
route(OUTBOUND-ROUTE-TRY);
}
route[OUTBOUND-ROUTE-TRY] {
if(dialog_count_of_vendor_gw < limit) {
t_on_failure("OUTBOUND-ROUTE-FAILURE");
if(!t_relay()) { sl_reply_error(); }
exit;
} else {
...
# Advance index of AVP array to next gateway, etc.
#
if(!t_lookup_request())
t_newtran();
route(OUTBOUND-ROUTE-TRY);
exit;
}
}
...
# Armed in OUTBOUND-ROUTE-TRY with t_on_failure().
failure_route[OUTBOUND-ROUTE-FAILURE] {
...
# If we have more routes to retry, call
# OUTBOUND-ROUTE-TRY again.
route(OUTBOUND-ROUTE-TRY);
}
However, what is happening to cause this error is a little different
from the usual scenario. On the initial attempt, the dialog limit
check you see in OUTBOUND-ROUTE-TRY is failing, so the route adds a
new transaction and calls itself again once.
Now, the reason I am creating a new transaction is because in certain
failure modes when a transaction was never created (like, if the call
also fails on the next attempt), it is otherwise not possible to send
a stateful failure reply to the originating endpoint from the failure
route, which is a requirement (one cannot issue stateless replies from
failure routes). So, because this routine is called both from the
failure route and from the request route, I create a new transaction
in order to make it possible to send stateful replies (t_reply()) from
within this route regardless of the type of the parent route calling
it, whether it is failure route or request route.
So, again, what is happening in the scenario in which I get the above
log message is:
1. INVITE is received
2. Master request route runs OUTBOUND-ROUTE-TRY request route
3. OUTBOUND-ROUTE-TRY checks gateway limit, finds it is exceeded
4. OUTBOUND-ROUTE-TRY checks request against existing transaction,
and if not found, creates a new one with t_newtran()
5. OUTBOUND-ROUTE-TRY calls itself again.
6. OUTBOUND-ROUTE-TRY succeeds this time, but evidently,
t_relay() fails with the above message, or above message appears
sometime before t_relay() is called.
Any insight is appreciated!
Thanks,
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
Hi,
I'm using kamailio 1.5.4-notls and I'm experimenting crashes when an UAC
sends an INVITE with a content-length greater then the effective body
length.
The error messages written on the logs is:
CRITICAL:core:del_lump: offset exceeds message size (1266 > 1161)
aborting...
and this is the backtrace of the generated core file:
#0 0x00002ad718ab307b in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00002ad718ab307b in raise () from /lib/libc.so.6
#1 0x00002ad718ab484e in abort () from /lib/libc.so.6
#2 0x0000000000418f53 in del_lump (msg=0x66de00, offset=1266, len=12,
type=HDR_OTHER_T) at data_lump.c:292
#3 0x00002ad71a8145ba in alter_mediaip (msg=0x66de00, body=<value optimized
out>, oldip=0x7fff81fe6700, oldpf=<value optimized out>,
newip=0x7fff81fe66e0, newpf=2, preserve=0)
at nathelper.c:1857
#4 0x00002ad71a821a3a in force_rtp_proxy (msg=0x66de00, str1=<value
optimized out>, str2=<value optimized out>, offer=<value optimized out>) at
nathelper.c:2871
#5 0x00002ad71a8238df in rtpproxy_offer1_f (msg=0x66de00, str1=0x65f370
"cof", str2=<value optimized out>) at nathelper.c:2391
#6 0x000000000040cc5a in do_action (a=0x65f400, msg=0x66de00) at
action.c:874
#7 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#8 0x0000000000454155 in eval_expr (e=0x65f4d0, msg=0x66de00, val=0x0) at
route.c:1171
#9 0x0000000000453bd7 in eval_expr (e=0x65f518, msg=0x66de00, val=0x0) at
route.c:1488
#10 0x0000000000453b7f in eval_expr (e=0x65f560, msg=0x66de00, val=0x0) at
route.c:1493
#11 0x000000000040c4c9 in do_action (a=0x65ffe8, msg=0x66de00) at
action.c:729
#12 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#13 0x000000000040dbc9 in do_action (a=0x660528, msg=0x66de00) at
action.c:746
#14 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#15 0x000000000040dbc9 in do_action (a=0x6606c8, msg=0x66de00) at
action.c:746
#16 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#17 0x000000000040dac5 in do_action (a=0x656790, msg=0x66de00) at
action.c:120
#18 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#19 0x000000000040dbc9 in do_action (a=0x656860, msg=0x66de00) at
action.c:746
#20 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#21 0x000000000040dac5 in do_action (a=0x6560b0, msg=0x66de00) at
action.c:120
#22 0x000000000040f19f in run_action_list (a=<value optimized out>,
msg=0x66de00) at action.c:145
#23 0x000000000040f4f3 in run_top_route (a=0x64b870, msg=0x66de00) at
action.c:120
#24 0x0000000000444e90 in receive_msg (
buf=0x619a20 "INVITE sip:xxxxxxxx@xxxxxxxxxxxx SIP/2.0\r\nVia:
SIP/2.0/UDP
xxx.xxx.xxx.xxx:xxxx;branch=z9hG4bK-d8754z-24245342621eb55b-1---d8754z-;rport\r\nMax-Forwards:
69\r\nContact: <sip:xxxxxxxx@xxx.xxx.xxx.xxx"..., len=1161,
rcv_info=0x7fff81fe86e0) at receive.c:175
#25 0x0000000000479254 in udp_rcv_loop () at udp_server.c:449
#26 0x0000000000427237 in main (argc=7, argv=0x7fff81fe88e8) at main.c:774
I couldn't get to reproduce this behavior in my test development (it has
newer version of glibc) in which I only get the messages:
ERROR:core:anchor_lump: offset exceeds message size (1125 > 714)...
ERROR:nathelper:force_rtp_proxy: anchor_lump failed
Looking into nathelper code, extract_body function I found that the
body->len value is taken from Content-Length header, so i added the
following piece of code:
--- nhelpr_funcs.c.orig 2010-09-02 14:04:09.891649254 +0200
+++ nhelpr_funcs.c 2010-09-02 14:17:40.183747107 +0200
@@ -196,6 +196,12 @@
LM_ERR("message body has length zero\n");
goto error;
}
+
+ if (body->len + body->s > msg->buf + msg->len) {
+ LM_ERR("content-length exceeds packet-length by %d\n",
+ (body->len + body->s) - (msg->buf +
msg->len));
+ body->len=strlen(body->s);
+ }
/* no need for parse_headers(msg, EOH), get_body will
* parse everything */
This way if the Content-Length header is greater then the effective body
length body->len is corrected with the real value.
This solved for the moment, but I'm not sure if this is a good approach and
I still don't understand why in the test platform I cannot reproduce the
crash.
Regards,
Federico Cabiddu
fyi, if you haven't discovered yourself yet (as it comes from ser repo),
this might be useful if you deal with big configs:
utils/route_graph/route_graph.py
It prints the tree of routes in your config, useful to understand configs,
detect loops or spot that some route was not called.
Next is the output for:
./utils/route_graph/route_graph.py etc/kamailio.cfg
Cheers,
Daniel
Main
|
\- REQINIT
|
\- NAT
|
\- WITHINDLG
| |
| \- RELAY
| | |
| | \- RTPPROXY
| |
| \- PRESENCE
|
\- AUTH
|
\- SIPOUT
| |
| \- RELAY
| | |
| | \- RTPPROXY
|
\- PRESENCE
|
\- REGISTRAR
|
\- PSTN
| |
| \- RELAY
| | |
| | \- RTPPROXY
|
\- LOCATION
|
\- RELAY
| |
| \- RTPPROXY
--
Daniel-Constantin Mierla
http://www.asipto.com
Using version 1.5.2.
Trying to migrate acc from db_mysql to db_flatstore to reduce io wait
during heavy dialing.
However, the default time format changes from normal YYYY-MM-DD hh:mm:ss
to unixtime in flatstore. I tried using $TF but its format is even more
non-standard.
Is there a way to change time format for either the default acc time
field in the db_flatstore module or $TF?
Thanks,
Matt
Hi SiP-Users,
I got kamailio installed and configured to work using mysql with FreeSWiTCH
using this HowTo wiki
freeswitch:kamailio-3.0.x-freeswitch-1.0.6d-ms [Asipto - SIP and VoIP
Knowledge Base Site]<http://kb.asipto.com/freeswitch:kamailio-3.0.x-freeswitch-1.0.6d-ms>:
http://kb.asipto.com/freeswitch:kamailio-3.0.x-freeswitch-1.0.6d-ms
This is also reference on FreeSWITCH portal and was the only decent tutorial
I was able to find on integrating Kamailio with FreeSWITCH.
Followed everything successfully, but I have a slight confusion/problem in
its wonderful working...
>From all tests I performed, I perceived following activities:
a.) it handled the extensions added to it very well, and carried over the
call to destination extension
b.) if destination extension is also added to it, call established without
intervention of FreeSWITCH
c.) if extension is not added to it but FreeSWITCH, the call reached
FreeSWITCH but was rejected there
d.) Red5Phone (developed over RED5 Server, @Google-Code) could dial with
success but didn't received any
Now,
*for point (a)* Thank You!
*for point (b)* it should be transferred to FreeSWITCH and that should be
allowed to establish call, otherwise all dial-plans,etc. goes waste
*for point (c)* may be some settings in Wiki are Obsolete OR New, could you
please point it out
*for point (d)* it may be due to point (b)
--
--
Regards,
Abhishek Kumar
https://sites.google.com/site/abhikumar163/
--
--------------ABK-----mail.signature--------------------
<http://www.blogger.com/profile/06276198262605731980><http://abhishekkr.deviantart.com/><http://www.facebook.com/aBionic><http://www.twitter.com/aBionic><http://sourceforge.net/users/abhishekkr><http://www.youtube.com/user/1ABK><http://in.linkedin.com/in/abionic>
-----------------------------------------------------------
~=ABK=~
Hi everyone,
We are looking at offloading routing logic out of our existing softswitch using openser as an external redirect server. Our routing logic is not terribly complicated and I think both carrierroute and LCR modules would be able to handle it but we have a pretty large route list table with around 30 million records (our routing table is 300k codes but keep different tables per client), 25-30 calls per sec would be enough.
>From a performance point of view, what would be the best bet within both modules? also, are both modules actively maintained?
Thanks,
Anthony
Hello all,
I am having little trouble routing registrations based on
route header in following configuration. UA sends registration to P1 and P1 is
ignoring “route header” and forwards registration request to Registrar.
I am using default kamailio configuration. Is there any thing I need to add to default config to enable route headers?
UA----------------->proxy1(kamailio)------------------->proxy2------------------>Registrar
REGISTER sip:Registrar.com
SIP/2.0
Via: SIP/2.0/UDP
10.18.0.67:5060;branch=z9hG4bKd209323e;rport
Route: <sip:proxy2.com;lr>
Max-Forwards: 70
From: <sip:xxxxxx@registrar.com>;tag=a85f9424
To: <sip:xxxxx@registrar.com>
Contact: <sip:xxxxxxx@10.18.0.67>
Call-ID: 431368ae25a3e232
CSeq: 100 REGISTER
Expires: 840
Allow:
INVITE,ACK,BYE,CANCEL,OPTIONS,UPDATE,SUBSCRIBE,NOTIFY
Supported:
User-Agent: xg-tx60 3.1.17 (VeriCall Edge)
Content-Length: 0
ThanksSid
"May the light be with you." ______________________________________________
Siddhardha Garige
www.luminepixels.com
