Hi,
I am trying to extract out the expires value from the incoming REGISTER
request. It might be present in the Contact header or as a separate Expires
header and hence I planned to use the $expires(max) PV to get this. But
kamailio just crashes as soon as I use the variable. Here's when it crashes:
if(is_method("REGISTER")) {
xlog("L_INFO", "Expires is $expires(max)");
if(!save("location", "0x01")) {
t_reply("500", "Error while saving AOR");
}
}
It crashes at the xlog point. …
[View More]Here's the backtrace for reference:
Reading symbols from /usr/local/kamailio/sbin/kamailio...done.
[New LWP 16609]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/kamailio/sbin/kamailio -P
/var/run/kamailio.pid -f /usr/local/kamail'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f34b658b311 in pv_get_expires (msg=0x7f34bd879e58,
param=0x7f34bd7e9220, res=0x7ffcf67af530) at pv_core.c:3060
3060 if(c->expires && c->expires->body.len) {
(gdb) backtrace
#0 0x00007f34b658b311 in pv_get_expires (msg=0x7f34bd879e58,
param=0x7f34bd7e9220, res=0x7ffcf67af530) at pv_core.c:3060
#1 0x00000000004fb6e1 in pv_get_spec_value (msg=0x7f34bd879e58,
sp=0x7f34bd7e9208, value=0x7ffcf67af530) at pvapi.c:1304
#2 0x00000000004fbb46 in pv_printf (msg=0x7f34bd879e58,
list=0x7f34bd80ef38, buf=0x7f34bd8735a0 "Expires is ", len=0x7ffcf67af618)
at pvapi.c:1363
#3 0x00007f34b67ea745 in xl_print_log (msg=0x7f34bd879e58,
list=0x7f34bd80ef38, buf=0x7f34bd8735a0 "Expires is ", len=0x7ffcf67af618)
at xl_lib.c:37
#4 0x00007f34b67eb0f9 in xlog_helper (msg=0x7f34bd879e58,
xm=0x7f34bd808648, level=2, line=0, facility=-1) at xlog.c:215
#5 0x00007f34b67ec160 in xlog_2_helper (msg=0x7f34bd879e58,
lev=0x7f34bd7e9130 "", frm=0x7f34bd808648 "84\177", mode=0, facility=-1)
at xlog.c:284
#6 0x00007f34b67ec19c in xlog_2 (msg=0x7f34bd879e58, lev=0x7f34bd7e9130
"", frm=0x7f34bd808648 "84\177") at xlog.c:292
#7 0x000000000041e23b in do_action (h=0x7ffcf67b0b40, a=0x7f34bd817cd0,
msg=0x7f34bd879e58) at action.c:1065
#8 0x000000000042a8e7 in run_actions (h=0x7ffcf67b0b40, a=0x7f34bd813e18,
msg=0x7f34bd879e58) at action.c:1548
#9 0x000000000041ab16 in do_action (h=0x7ffcf67b0b40, a=0x7f34bd7e8738,
msg=0x7f34bd879e58) at action.c:677
#10 0x000000000042a8e7 in run_actions (h=0x7ffcf67b0b40, a=0x7f34bd7e8738,
msg=0x7f34bd879e58) at action.c:1548
#11 0x000000000041e094 in do_action (h=0x7ffcf67b0b40, a=0x7f34bd7e89c8,
msg=0x7f34bd879e58) at action.c:1044
#12 0x000000000042a8e7 in run_actions (h=0x7ffcf67b0b40, a=0x7f34bd7e19d8,
msg=0x7f34bd879e58) at action.c:1548
#13 0x000000000042b04d in run_top_route (a=0x7f34bd7e19d8,
msg=0x7f34bd879e58, c=0x0) at action.c:1634
#14 0x000000000050f3d4 in receive_msg (
buf=0xa80c00 <buf> "REGISTER sip:devsip.tlkn.com SIP/2.0\r\nVia:
SIP/2.0/UDP 203.153.53.145:8300;branch=z9hG4bK119a.e23ed10b856f38b41c93d1d259d8869f.0;i=b1\r\nVia:
SIP/2.0/TCP 172.16.16.32:52358;rport=52359;received=203.153."..., len=712,
rcv_info=0x7ffcf67b0e60) at receive.c:196
#15 0x0000000000613b9e in udp_rcv_loop () at udp_server.c:495
#16 0x00000000004aa119 in main_loop () at main.c:1577
#17 0x00000000004b0e1e in main (argc=5, argv=0x7ffcf67b1318) at main.c:2553
Thanks,
- Jayesh
[View Less]
Hi Folks,
I have a problem with To and From headers in 200 OK to BYE request. Their
URI is doubled when leaving Kamailio.
Incoming 200 OK:
From : <sip:00421111@IP_ADDRESS>;tag=as017a2986
To : <sip:00421222@IP_ADDRESS0>;tag=K7ryDgH2g7gFm
Outgoing 200 OK:
From : <sip:+421111@IP_ADDRESS><sip:+421111@IP_ADDRESS>;tag=as017a2986
To : <sip:+421222@IP_ADDRESS><sip:+421222@IP_ADDRESS>;tag=K7ryDgH2g7gFm
I'm using uac module to replace these headers in auto …
[View More]and dialog mode:
modparam("uac", "restore_mode", "auto")
modparam("uac", "restore_dlg", 1)
append_fromtag is also set:
modparam("rr", "append_fromtag", 1)
When I run kamailio in debug mode I can see the function
restore_uri_reply() is called twice:
.
.
.
0(3133) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found
param type 234, <received> = <IP_ADDRESS>; state=6
0(3133) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found
param type 232, <branch> = <z9hG4bK0bb8c5b2>; state=6
0(3133) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found
param type 235, <rport> = <5060>; state=16
0(3133) DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of
header reached, state=5
0(3133) DEBUG: <core> [parser/msg_parser.c:513]: parse_headers():
parse_headers: Via found, flags=62
0(3133) DEBUG: <core> [parser/msg_parser.c:526]: parse_headers():
parse_headers: this is the second via
0(3133) DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param():
DEBUG: add_param: tag=teHD72X67aQUm
0(3133) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec():
end of header reached, state=29
0(3133) DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG:
get_hdr_field: <To> [60]; uri=[sip:421222@IP_ADDRESS:5060]
0(3133) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG:
to body [<sip:421222@IP_ADDRESS:5060>]
0(3133) DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field():
get_hdr_field: cseq <CSeq>: <103> <BYE>
0(3133) DEBUG: tm [t_lookup.c:949]: t_reply_matching(): DEBUG:
t_reply_matching: hash 10806 label 0 branch 0
0(3133) DEBUG: tm [t_lookup.c:1004]: t_reply_matching(): DEBUG:
t_reply_matching: reply matched (T=0x220071b4)!
0(3133) DEBUG: tm [t_hooks.c:288]: run_trans_callbacks_internal(): DBG:
trans=0x220071b4, callback type 2, id 0 entered
0(3133) DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param():
DEBUG: add_param: tag=as46bccb83
0(3133) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec():
end of header reached, state=29
0(3133) DEBUG: uac [replace.c:705]: restore_uri_reply(): removing
<<sip:00421111@IP_ADDRESS>>
0(3133) DEBUG: uac [replace.c:714]: restore_uri_reply(): inserting
<<sip:+421111@IP_ADDRESS>>
0(3133) DEBUG: uac [replace.c:705]: restore_uri_reply(): removing
<<sip:00421222@IP_ADDRESS>>
0(3133) DEBUG: uac [replace.c:714]: restore_uri_reply(): inserting
<<sip:+421222@IP_ADDRESS>>
0(3133) DEBUG: tm [t_hooks.c:288]: run_trans_callbacks_internal(): DBG:
trans=0x220071b4, callback type 2, id 0 entered
0(3133) DEBUG: uac [replace.c:705]: restore_uri_reply(): removing
<<sip:00421111@IP_ADDRESS>>
0(3133) DEBUG: uac [replace.c:714]: restore_uri_reply(): inserting
<<sip:+421111@IP_ADDRESS>>
0(3133) DEBUG: uac [replace.c:705]: restore_uri_reply(): removing
<<sip:00421222@IP_ADDRESS>>
0(3133) DEBUG: uac [replace.c:714]: restore_uri_reply(): inserting
<<sip:+421222@IP_ADDRESS>>
.
.
.
I think the problem is in registering a function restore_uris_reply() in
callbacks in functions (both in replace.c of uac module)
* void rr_checker(struct sip_msg *msg, str *r_param, void *cb_param)
* static void replace_callback(struct dlg_cell *dlg, int type, struct
dlg_cb_params *_params)
Both of these callbacks are registered for BYE and ACK requests (INVITE
request is using different callback), therefore running restore_uri_reply()
twice.
For testing purposes after I have removed the callback in rr_checker and
recompile the uac module, To and From headers were OK.
In my configuration I'm calling uac_replace_to in RELAY route:
route[RELAY]
{
if ( !has_totag() ) {
dlg_manage();
uac_replace_to("$ru");
}
if (!t_relay())
{
sl_reply_error();
}
}
So I think there is a bug in uac module, when one function is registered
twice in callbacks for NON-INVITE requests.
Or is there a problem with my configuration script?
Can anyone point me to the direction how to solve this issue?
Thank you
Efelin
Kamailio version: kamailio 4.4.0-dev6 (i386/linux) a66e22-dirty
[View Less]
Hello everyone!
Subj is an ethernal theme, I know, but odds are so that I just need to do
that.
I've configured UAC auth to successfully register and my route[PSTN] looks
like that
# check if PSTN GW IP is defined
if (strempty($sel(cfg_get.pstn.gw_ip))) {
xlog("SCRIPT: PSTN routing enabled but pstn.gw_ip not
defined\n");
return;
}
if !ds_is_from_list()
return;
# route to PSTN dialed numbers starting with '…
[View More]+' or '00'
# (international format)
# - update the condition to match your dialing rules for PSTN
routing
if(!($rU=~"^(\+|00)[1-9][0-9]{3,20}$"))
return;
if (strempty($sel(cfg_get.pstn.gw_port))) {
$ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip);
} else {
$ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip) + ":"
+ $sel(cfg_get.pstn.gw_port);
}
remove_hf("To");
insert_hf("To: <sip:$rU@sipprovider.com>\r\n", "Call-ID");
uac_replace_from("","sip:user@sipprovider.com");
route(RELAY);
exit;
On INVITE's I get 407 PROXY-AUTH, which are transfered to backend FS.
If I try to put
if ($T_reply_code == 401 or $T_reply_code == 407) {
xlog("L_NOTICE", "Remote asked for authentication");
uac_auth();
}
to MANAGE_FAILURE or MANAGE_REPLY route Kamailio can't start.
Is that even possible?
--
Alexandru Covalschi
ABRISS-Solutions
VoIP engineer and system administrator
phone: +37367398493
web: http://abs-telecom.com/
[View Less]
Hi guys,
I use kamailio with mysql. Some queries are huge and when I need to debug
something it takes a time, so the debbuging would be easier.
Is there any way how could I log all sql queries into a log file ?
Thanks,
John
What is the best way to find out address family (IPV4 or IPV6) of media in SDP?
My goal is to reject INVITEs which have different address families in headers
and SDP, i.e. IPv4 INVITE with IPv6 media address in SDP and vice versa.
I've installed Kamailio on 2 different servers.
They share the same PostgreSQL database for users etc.
I've setup a single domain, sip.my-domain.com, with latency responds to the
2 servers.
So a user will always land on the server with the fastest responds in a
respective area of the world.
However, it seems as if 2 users are registered on different Kamailio
servers - even though they share the same database - they cannot call each
other?
Have I misunderstood something?
I've enabled WITH_NAT.
I am facing an issue with kamailio 4.3.3 that is very similar to
http://lists.sip-router.org/pipermail/sr-users/2015-May/088195.html
Had someone found the solution or faced similar issue ?
Sometimes kamailio is receiving the message (check with wireshark, logs in
tcp) but the message is not handled nor relayed.
After a certain amount of time everything works fine.
I will do what as has been advised : enabling pike & check with gdb when it
appears.
thibault
hello how are you?
i have a problem using sipcapture module
i'm writing in postgres database some sip messages but the msg field is
stored ina strange format,
\x5349502f322e30203438372052657175657374205465726d696e61746
5640d0a5669613a205349502f322e302f5544502037392e3137302e36342e3136383a353038303b6272616e63683d7a39684734624b30583665375a70394e446533513b72656365697665643d37392e3137302e36342e3136383b72706f72743d353038300d0a5265636f72642d526f7574653a
…
[View More]203c7369703a3139302e3136362e3233322e3139333a393236323b7472616e73706f72743d7564703b6c723e2c3c7369703a37392e3137302e36382e3138363b6c723b667461673d394448397648374435444653653b6469643d3639612e616437393e0d0a43616c6c2d49443a2033323666333
037632d373138642d346164392d393234362d3333336432323466613439380d0a46726f6d3a2022313931373838393437363922203c7369703a31393137383839343736394037392e3137302e36342e3136383e3b7461673d394448397648374435444653650d0a546f3a203c7369703a313830
39323935373838374037392e3137302e36382e3138363a353036303b757365723d70686f6e653e3b7461673d736263303830367974646c746f6c302d43432d33300d0a435365713a20383338353333383820494e564954450d0a5761726e696e673a203339392031302e31382e352e363420225
353313230303031463135364c3934345b30303030305d2043616e63656c207265636569766564206f6e20696e697469616c20696e76697465220d0a436f6e74656e742d4c656e6774683a20300d0a0d0a
do you know how to configure it to see it in ascii?
thanks a lot and regards
david escartin
[View Less]
Reminder: speaker's deadline this Friday, 27 November at 23:59 UTC
We have already received several really exciting talk proposals
but there is still time for people to propose talks or encourage
friends or colleagues to speak.
Many other dev-rooms also have a deadline in the next few days and if
your topic is applicable to more than one dev-room, you are welcome
to make more than one submission. Please contact us or put a note in
the memo field at the top of the talk proposal if you do that.…
[View More]
All projects are encouraged to consider making a lightning talk too,
it is an excellent opportunity to get exposure for your project:
even though you only have 15 minutes, it can be a much larger and more
diverse audience than in some dev-rooms.
For full details, please see the call for papers:
http://danielpocock.com/fosdem-2016-free-rtc-dev-room-and-lounge
We invite all potential speakers and participants to discuss the selection
process and other aspects of FOSDEM on the Free-RTC mailing list:
https://lists.fsfe.org/mailman/listinfo/free-rtc
[View Less]