Hi,
I am using Kamailio version: kamailio 4.3.0 (x86_64/linux) c6aa95 on CentOS 6
I am trying to encapsulate ISUP in the INVITE:
```
...
if(has_body("application/sdp"))
{
set_body_multipart();
if(msg_apply_changes())
{
$var(isup) = "7e Od 04 55 75 69 20 4d 61 6b 65 43 61 6c 6c";
append_body_part("$var(isup)","application/isup; version=itu-t92+","signal; handling=optional");
xlog("L_INFO", "ISUP Changes Applied Succesfully");
}
}
ds_select_dst("2","8");
...
```
And getting the following error:
```
kamailio: DEBUG: <core> [msg_translator.c:1691]: get_boundary(): boundary is <--unique-boundary-1>
...
kamailio: DEBUG: <core> [msg_translator.c:1808]: check_boundaries(): last bondary without -- at the end
kamailio: DEBUG: <core> [msg_translator.c:1612]: replace_body(): old size body[365] actual[534]
kamailio: CRITICAL: <core> [data_lump.c:463]: free_lump(): non free-able lump: 0x7f7a33d5ae40 flags=1
```
and then Kamailio crashes.
DEBUG:
```
Jul 9 15:21:56 kamailiohost kamailio: DEBUG: <core> [msg_translator.c:1808]: check_boundaries(): last bondary without -- at the end
Jul 9 15:21:56 kamailiohost kamailio: DEBUG: <core> [msg_translator.c:1612]: replace_body(): old size body[365] actual[513]
Jul 9 15:21:56 kamailiohost kamailio: CRITICAL: <core> [data_lump.c:463]: free_lump(): non free-able lump: 0x7fc340edc270 flags=1
```
Can you please recommend?
p.s. as per: http://lists.sip-router.org/pipermail/sr-users/2015-July/089018.html
Thanks,
Andrei
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/240
Hi, we use pretty recent kamailio:
```
version: kamailio 4.4.0-dev2 (x86_64/linux) 1a758d
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, DBG_F_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 1a758d
compiled on 14:49:47 Jul 20 2015 with gcc 4.8.2
```
The case:
consider the mobile SIP agent which switches between networks (e.g. wifi -> mobile) during the call. It sends re-INVITE with its new location.
We use keep-alives provided by dialog module. And it seems that keep-alives don't use new address and are always sent to initial address.
Any thoughts?
Thanks.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/273
I'm observing a segmentation fault when mongodb & tls enabled. It doesn't happen when one of the module is disabled.
OS: centos 6.7 kamailio 4.3.2 mongo-c-driver version 1.1.10.
It happens immediately after i register a subscriber. The location table is updated with the new data and in parallel core is generated as well.
I'm running with the offical kamailio script by just enabling mongo modules. It happens for NDB as well.
How did you build the mongo driver when you implemented it? May be i can try the same.
Please find the scripts used for testing in the email.
Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio.pid -m 64 -M 8'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f85a21da075 in lock_udomain (_d=0x7f859c7b5f08, _aor=0x7fff6de7ef70) at udomain.c:1017
1017 lock_get(_d->table[sl].lock);
Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.23-15.el6_6.2.x86_64 cyrus-sasl-plain-2.1.23-15.el6_6.2.x86_64 db4-4.7.25-19.el6_6.x86_64 glibc-2.12-1.166.el6_7.1.x86_64 keyutils-libs-1.4-5.el6.x86_64 krb5-libs-1.10.3-42.el6.x86_64 libcom_err-1.41.12-22.el6.x86_64 libselinux-2.0.94-5.8.el6.x86_64 nss-softokn-freebl-3.14.3-22.el6_6.x86_64 openssl-1.0.1e-42.el6.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0 0x00007f85a21da075 in lock_udomain (_d=0x7f859c7b5f08, _aor=0x7fff6de7ef70) at udomain.c:1017
#1 0x00007f85a1d7069b in add_contacts (_m=0x7f85a3f054b8, _d=0x7f859c7b5f08, _a=0x7fff6de7ef70, _mode=0, _use_regid=1) at save.c:831
#2 0x00007f85a1d72602 in save (_m=0x7f85a3f054b8, _d=0x7f859c7b5f08, _cflags=0, _uri=0x0) at save.c:986
#3 0x00007f85a1d5975a in w_save2 (_m=0x7f85a3f054b8, _d=0x7f859c7b5f08 "h^{\234\205\177", _cflags=0x0) at reg_mod.c:414
#4 0x000000000041decb in do_action (h=0x7fff6de7f720, a=0x7f85a3edd830, msg=0x7f85a3f054b8) at action.c:1059
#5 0x000000000042a553 in run_actions (h=0x7fff6de7f720, a=0x7f85a3edd830, msg=0x7f85a3f054b8) at action.c:1548
#6 0x000000000042abb8 in run_actions_safe (h=0x7fff6de80a10, a=0x7f85a3edd830, msg=0x7f85a3f054b8) at action.c:1613
#7 0x0000000000543d50 in rval_get_int (h=0x7fff6de80a10, msg=0x7f85a3f054b8, i=0x7fff6de7fbf8, rv=0x7f85a3edf478, cache=0x0) at rvalue.c:912
#8 0x0000000000547f88 in rval_expr_eval_int (h=0x7fff6de80a10, msg=0x7f85a3f054b8, res=0x7fff6de7fbf8, rve=0x7f85a3edf470) at rvalue.c:1906
#9 0x000000000054837e in rval_expr_eval_int (h=0x7fff6de80a10, msg=0x7f85a3f054b8, res=0x7fff6de80080, rve=0x7f85a3edfb70) at rvalue.c:1914
#10 0x000000000041d927 in do_action (h=0x7fff6de80a10, a=0x7f85a3ee0270, msg=0x7f85a3f054b8) at action.c:1029
#11 0x000000000042a553 in run_actions (h=0x7fff6de80a10, a=0x7f85a3edc990, msg=0x7f85a3f054b8) at action.c:1548
#12 0x000000000041a8c3 in do_action (h=0x7fff6de80a10, a=0x7f85a3ebdd98, msg=0x7f85a3f054b8) at action.c:677
#13 0x000000000042a553 in run_actions (h=0x7fff6de80a10, a=0x7f85a3ebdb08, msg=0x7f85a3f054b8) at action.c:1548
#14 0x000000000042ac80 in run_top_route (a=0x7f85a3ebdb08, msg=0x7f85a3f054b8, c=0x0) at action.c:1634
#15 0x000000000050a9f4 in receive_msg (
buf=0xa70b00 "REGISTER sip:192.168.2.142 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.2.119:60887;branch=z9hG4bK-524287-1---d670bd2004732b4a;rport\r\nMax-Forwards: 70\r\nContact: <sip:usera@192.168.2.119:60887;rinstance=d9f6274d7"..., len=534, rcv_info=0x7fff6de80d00) at receive.c:196
#16 0x000000000060a4a6 in udp_rcv_loop () at udp_server.c:495
#17 0x00000000004a7fb3 in main_loop () at main.c:1573
#18 0x00000000004ae38e in main (argc=7, argv=0x7fff6de81138) at main.c:2533
(gdb) quit
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/360
Hey guys,
Not sure if there have been any changes but I have an interesting problem
here when using TCP:
*The BT is as follows:*
#0 local_timer_list_expire (h=0xa0f128 <tcp_reader_ltimer+178664>,
t=723807134, l=0x9e3740 <tcp_reader_ltimer>) at local_timer.c:198
#1 local_timer_expire (t=723807134, h=<optimized out>) at local_timer.c:227
#2 local_timer_run (lt=lt@entry=0x9e3740 <tcp_reader_ltimer>,
saved_ticks=723807150) at local_timer.c:250
#3 0x00000000005d8417 in tcp_reader_timer_run () at tcp_read.c:1682
#4 tcp_receive_loop (unix_sock=<optimized out>) at tcp_read.c:1734
#5 0x00000000005c81c8 in tcp_init_children () at tcp_main.c:4788
#6 0x00000000004a9da3 in main_loop () at main.c:1664
#7 0x000000000042411e in main (argc=<optimized out>, argv=<optimized out>)
at main.c:2566
This seems to be related to clearing timers for TCP connections. The crash
is related to the following code:
*_timer_rm_list(tl)*
where it does a null pointer deref on tl->next and tl->prev, which,
according to the bt, are null (see below).
*(gdb) print *tl*
$14 = {next = 0x0, prev = 0x0, expire = 723807134, initial_timeout = 32,
data = 0x7fbbb05aa628, f = 0x5d02f0 <tcpconn_read_timeout>, flags = 512,
slow_idx = 0}
Any ideas?
Cheers
Jason
The commit contains pua_usrloc modifications, which simplifies the publish and regisration processes: in every REGISTER an implicit publish is built in. In this way, a device e.g. do not need to send two individual request towards kamailio (REGISTER, PUBLISH), it can be achieved in a single but extended REGISTER request.
Another small fix is that if the publication is expired (due to broken TCP e.g.), a "closed" NOTIFY should be sent to the contacts.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/177
-- Commit Summary --
* Adding publish in registration functionality
-- File Changes --
M modules/pua_usrloc/pua_usrloc.c (4)
M modules/pua_usrloc/ul_publish.c (152)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/177.patchhttps://github.com/kamailio/kamailio/pull/177.diff
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/177
Right now kamailio.service is available in pkg/kamailio/fedora/17 but not in pkg/kamailio/deb.
With both Ubuntu and Debian switched to systemd it would make sense to unify packaging and use .service for deb packages as well.
In addition to give users chance to better test this before next LTS release it might make sense to add builds for ubuntu 15.04 too.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/294
Kex module updated to also give some details about memory used by each module.
Changed f_*, q_* and tlsf_* memory stubs to also include the module name.
Added 2 new memory API functions(for each of the memory algos) which will
iterate throughout the memory fragments and agregate the memory size used by
each function in order to print it.
Tested with MEMMNG=0,1,2 and MEMDBG=0,1. Use "kamcmd mem.stat mod_name pkg/shm/all" to test
Updated doku.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/225
-- Commit Summary --
* kex: per module memory debugging
-- File Changes --
M events.c (25)
M events.h (4)
M mem/f_malloc.c (135)
M mem/f_malloc.h (47)
M mem/mem.h (32)
M mem/q_malloc.c (113)
M mem/q_malloc.h (40)
M mem/shm_mem.c (4)
M mem/shm_mem.h (32)
M mem/src_loc.h (2)
M mem/tlsf.c (105)
M mem/tlsf.h (32)
M modules/ctl/binrpc_run.c (12)
M modules/kex/doc/kex_admin.xml (76)
M modules/kex/kex_mod.c (7)
A modules/kex/mod_stats.c (288)
A modules/kex/mod_stats.h (37)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/225.patchhttps://github.com/kamailio/kamailio/pull/225.diff
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/225
Would be nice if Kamailio could log various events directly to journald bypassing syslog. This would make logging much more accessible, structured and secure. Also additional meta-data could be saved directly. This would also greatly simplify exporting logs in a structured way using journald's json facilities. The backward compatibility will be preserved automatically by journald.
Here is relevant write-up: http://0pointer.de/blog/projects/journal-submit.html
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/370