sr-users July 2017

sr-users@lists.kamailio.org

69 participants
95 discussions

fix_nated_contact and IPv6
by Sebastian Damm 27 Oct '17

27 Oct '17

Hi, I'm trying to set up a Kamailio (4.1.3) server which converts between IPv6 and IPv4. Everything looks pretty good. Now I have a test client which sends packets via IPv6, but in contact header, SDP etc. there are still IPv4 addresses. (This comes from some converting from v4 to v6 earlier.) Thus, Kamailio tries to do a fix_nated_contact(). But after fixing, the Contact URI is wrong. Example: inbound Contact: <sip:bob@192.168.8.132> outbound Contact: <sip:bob@1234:1234:0:1234:0:0:0:2> The correct way of transforming the Contact URI would be: Contact: <sip:bob@[1234:1234:0:1234:0:0:0:2]> This incorrect Contact URI doesn't hurt first, but when the called party wants to hang up the call, it addresses the URI from Contact header, and Kamailio can't parse the Request URI: Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: pv [pv_core.c:304]: pv_get_ruri_attr(): failed to parse the R-URI Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: rr [loose.c:934]: loose_route(): failed to parse Request URI Jan 22 12:03:48 router /usr/sbin/kamailio[21309]: ERROR: domain [domain.c:140]: is_uri_host_local(): error while parsing R-URI Is this a bug in the nathelper module? Was it never meant to handle IPv6 addresses? Or do I understand something wrong? Best Regards, Sebastian

4 4

NatHelper ignoring force_socket module parameter
by Asgaroth 24 Oct '17

24 Oct '17

Hi All, I have a strange issue, I have set the module parameter for nathelper's force_socket to a specfic ip/port, however, when I perform a sip trace I can see that all locally generated options messages are not sent from the socket defined in the modules parameters. I am not setting $fs anywhere in the script, so I am not over-writing it. Do any of the other module parameters have a bearing on if nathelper uses the force_socket parameter? My current nathelper settings are: modparam("nathelper", "received_avp", "$avp(RECEIVED)") modparam("nathelper", "natping_interval", 20) modparam("nathelper", "natping_processes", 4) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_from", "sip:keepalive@domain.com") modparam("nathelper", "sipping_method", "OPTIONS") modparam("nathelper", "sipping_bflag", NAT_BFLAG) modparam("nathelper", "force_socket", "1.2.3.4:5060") I am using kamailio v4.3.1: # kamailio -V version: kamailio 4.3.1 (x86_64/linux) f38e67 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: f38e67 compiled on 18:15:23 Jul 20 2015 with gcc 4.4.7 Thanks

2 5

Kamailio IMS deployment
by Ramya Y 22 Oct '17

22 Oct '17

Hi, I am newbie to kamailio world and we would like to deploy Kamailio based IMS platform. Can any body share the link or Step by step procedure(user Guide) to deploy Kamailio IMS. Regards, Ramya

5 22

issue when trying to start kamailio using db_postgres and dialplan modules
by David Escartín 04 Oct '17

04 Oct '17

hello all we are having an issue when trying to start kamailio using these modules and a kamailio version higher than 4.2 we install libpq5 and libpq-dev and we always have this error 0(10800) ERROR: <core> [core/sr_module.c:582]: load_module(): could not open module </usr/local/kamailio-5.0/lib64/kamailio/modules/db_postgres.so>: /usr/local/kamailio-5.0/lib64/kamailio/modules/db_postgres.so: undefined symbol: PQconnectdbParams do you know which lib or packet would we miss? we are trying to install it on centos6, ubuntu 10 or centos7 best regards david

2 3

Kamailio 4.3.4: receive_msg(): no via found in reply
by Grant Bagdasarian 15 Aug '17

15 Aug '17

Hello, We're testing kamailio 4.3.4 with two kamailio's communicating with each other. One of them is a gateway with rtpengine at the carrier side, the other is a basic sip router. When calling a destination and cancelling the INVITE a 487 is received from the carrier and directly ACK'd by the first kamailio and in turn is forwarded to the second. But the 487 response received by the 2nd kamailio doesn't have a Via header which results in kamailio printing the error: receive_msg(): no via found in reply. Any ideas why the forwarded 487 doesn't contain a Via header and how to fix this? Note: IP's are changed. Carrier: 10.0.0.1 Kamailio 1: 10.14.0.1 Kamailio 2: 10.14.0.2 U 10.0.0.1:5060 -> 10.14.0.1:5060 SIP/2.0 487 Request Cancelled. Via: SIP/2.0/UDP 10.14.0.1;branch=z9hG4bK8e28.642c68037d059634308d4be8fe3f0cdc.0. From: "+31612345678" <sip:+31612345678@10.14.0.3:5060>;tag=109ac722. To: <sip:003112345678@10.14.0.3:5060>;tag=sbcsipuas_1_C22196_20160314080307791_b59sb10. Call-ID: 78100MjY3OGExZmMyODU2MzAyMzM5ODA3MmNhMDdlMzg0MzU. Contact: <sip:10.0.0.1:5060>. CSeq: 2 INVITE. Server: sbc_5. Content-Length: 0. . # U 10.14.0.1:5060 -> 10.0.0.1:5060 ACK sip:003112345678@10.0.0.1:5060 SIP/2.0. Via: SIP/2.0/UDP 10.14.0.1;branch=z9hG4bK8e28.642c68037d059634308d4be8fe3f0cdc.0. Max-Forwards: 67. To: <sip:003112345678@10.14.0.3:5060>;tag=sbcsipuas_1_C22196_20160314080307791_b59sb10. From: "+31612345678"<sip:+31612345678@10.14.0.3:5060>;tag=109ac722. Call-ID: 78100MjY3OGExZmMyODU2MzAyMzM5ODA3MmNhMDdlMzg0MzU. CSeq: 2 ACK. Content-Length: 0. . # U 10.14.0.1:5060 -> 10.14.0.2:5060 SIP/2.0 487 Request Cancelled. From: "+31612345678" <sip:+31612345678@10.14.0.3:5060>;tag=109ac722. To: <sip:003112345678@10.14.0.3:5060>;tag=sbcsipuas_1_C22196_20160314080307791_b59sb10. Call-ID: 78100MjY3OGExZmMyODU2MzAyMzM5ODA3MmNhMDdlMzg0MzU. Contact: <sip:10.0.0.1:5060>. CSeq: 2 INVITE. Server: sbc_5. Content-Length: 0.

4 16

Core crash in del_lump() "offset exceeds message size" when using subst() inside tm:local-request route.
by Cody Herzog 08 Aug '17

08 Aug '17

Hello. Inside the tm:local-request route, I am trying to modify the body of outgoing NOTIFY messages using the subst_body() function. Things seem to work fine most of the time. The NOTIFY messages are correctly modified. However, I will very rarely hit a crash. I can force the crash to happen more quickly by stress testing with thousands of NOTIFY messages being modified. Is it safe to call subst() or subst_body() inside the tm:local-request route? If not, is there another way I can modify the outgoing NOTIFY messages safely? Note that I am also calling append_hf() inside the same tm:local-request route, but that has been working for a very long time without causing any problems. Could there be some kind of bad interaction between append_hf() and subst_body()? Strangely, it seems like using subst() makes the crash more likely to happen. For some reason, subst_body() seems to be more robust. Here are the logs I see: --------- Jul 28 10:57:40 SIPCOMM-VEGAS-TEST /usr/local/sbin/kamailio[2476]: CRITICAL: <core> [data_lump.c:292]: del_lump(): offset exceeds message size (1625 > 1194) aborting... Jul 28 10:57:43 SIPCOMM-VEGAS-TEST /usr/local/sbin/kamailio[2481]: CRITICAL: <core> [pass_fd.c:275]: receive_fd(): EOF on 53 Jul 28 10:57:44 SIPCOMM-VEGAS-TEST /usr/local/sbin/kamailio[2367]: ALERT: <core> [main.c:731]: handle_sigs(): child process 2476 exited by a signal 6 Jul 28 10:57:44 SIPCOMM-VEGAS-TEST /usr/local/sbin/kamailio[2367]: ALERT: <core> [main.c:734]: handle_sigs(): core was generated Jul 28 10:57:44 SIPCOMM-VEGAS-TEST /usr/local/sbin/kamailio[2367]: INFO: <core> [main.c:756]: handle_sigs(): terminating due to SIGCHLD --------- Here is a GDB back trace from the core dump: --------- #0 0x00007fd91a567c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007fd91a56b028 in __GI_abort () at abort.c:89 #2 0x000000000044e981 in del_lump (msg=0x7fd917c5ed60 <lreq>, offset=1625, len=20, type=HDR_OTHER_T) at data_lump.c:293 #3 0x00007fd91676297f in subst_f (msg=0x7fd917c5ed60 <lreq>, subst=0x7fd919e5ccc0 "\320\356\345\031\331\177", ignored=0x0) at textops.c:681 #4 0x000000000041e1dd in do_action (h=0x7ffd364b87c0, a=0x7fd919e9b438, msg=0x7fd917c5ed60 <lreq>) at action.c:1059 #5 0x000000000042a917 in run_actions (h=0x7ffd364b87c0, a=0x7fd919e9b438, msg=0x7fd917c5ed60 <lreq>) at action.c:1548 #6 0x000000000042af94 in run_actions_safe (h=0x7ffd364ba5b0, a=0x7fd919e9b438, msg=0x7fd917c5ed60 <lreq>) at action.c:1613 #7 0x0000000000549972 in rval_get_int (h=0x7ffd364ba5b0, msg=0x7fd917c5ed60 <lreq>, i=0x7ffd364b8b58, rv=0x7fd919e9ced8, cache=0x0) at rvalue.c:912 #8 0x000000000054dc7c in rval_expr_eval_int (h=0x7ffd364ba5b0, msg=0x7fd917c5ed60 <lreq>, res=0x7ffd364b8b58, rve=0x7fd919e9ced0) at rvalue.c:1910 #9 0x000000000041dc52 in do_action (h=0x7ffd364ba5b0, a=0x7fd919e9d990, msg=0x7fd917c5ed60 <lreq>) at action.c:1029 #10 0x000000000042a917 in run_actions (h=0x7ffd364ba5b0, a=0x7fd919e9d990, msg=0x7fd917c5ed60 <lreq>) at action.c:1548 #11 0x000000000041e0c4 in do_action (h=0x7ffd364ba5b0, a=0x7fd919e9dad8, msg=0x7fd917c5ed60 <lreq>) at action.c:1044 #12 0x000000000042a917 in run_actions (h=0x7ffd364ba5b0, a=0x7fd919e973b8, msg=0x7fd917c5ed60 <lreq>) at action.c:1548 #13 0x000000000041ab46 in do_action (h=0x7ffd364ba5b0, a=0x7fd919e95d70, msg=0x7fd917c5ed60 <lreq>) at action.c:677 #14 0x000000000042a917 in run_actions (h=0x7ffd364ba5b0, a=0x7fd919e8f330, msg=0x7fd917c5ed60 <lreq>) at action.c:1548 #15 0x000000000041e0c4 in do_action (h=0x7ffd364ba5b0, a=0x7fd919e95eb8, msg=0x7fd917c5ed60 <lreq>) at action.c:1044 #16 0x000000000042a917 in run_actions (h=0x7ffd364ba5b0, a=0x7fd919e8c8e0, msg=0x7fd917c5ed60 <lreq>) at action.c:1548 #17 0x000000000042b07d in run_top_route (a=0x7fd919e8c8e0, msg=0x7fd917c5ed60 <lreq>, c=0x0) at action.c:1634 #18 0x00007fd917a0539a in t_uac_prepare (uac_r=0x7ffd364baf20, dst_req=0x7ffd364ba8f0, dst_cell=0x7ffd364ba8f8) at uac.c:391 #19 0x00007fd917a07945 in t_uac_with_ids (uac_r=0x7ffd364baf20, ret_index=0x0, ret_label=0x0) at uac.c:599 #20 0x00007fd917a07918 in t_uac (uac_r=0x7ffd364baf20) at uac.c:584 #21 0x00007fd917a09b9e in req_within (uac_r=0x7ffd364baf20) at uac.c:802 #22 0x00007fd914674052 in send_notify_request (subs=0x7ffd364bb200, watcher_subs=0x0, n_body=0x0, force_null_body=0) at notify.c:1600 #23 0x00007fd9146754b3 in notify (subs=0x7ffd364bb200, watcher_subs=0x0, n_body=0x0, force_null_body=0) at notify.c:1690 #24 0x00007fd9146cec6a in update_subscription (msg=0x7fd919efeb70, subs=0x7ffd364bb200, to_tag_gen=1, sent_reply=0x7ffd364bb16c) at subscribe.c:697 #25 0x00007fd9146d45b7 in handle_subscribe (msg=0x7fd919efeb70, watcher_user=..., watcher_domain=...) at subscribe.c:1057 #26 0x00007fd9146d08b0 in handle_subscribe0 (msg=0x7fd919efeb70) at subscribe.c:816 #27 0x000000000041e155 in do_action (h=0x7ffd364bd680, a=0x7fd919e19508, msg=0x7fd919efeb70) at action.c:1053 #28 0x000000000042a917 in run_actions (h=0x7ffd364bd680, a=0x7fd919e19508, msg=0x7fd919efeb70) at action.c:1548 #29 0x000000000041e112 in do_action (h=0x7ffd364bd680, a=0x7fd919e19650, msg=0x7fd919efeb70) at action.c:1048 #30 0x000000000042a917 in run_actions (h=0x7ffd364bd680, a=0x7fd919e02638, msg=0x7fd919efeb70) at action.c:1548 #31 0x000000000041e0c4 in do_action (h=0x7ffd364bd680, a=0x7fd919e199c0, msg=0x7fd919efeb70) at action.c:1044 #32 0x000000000042a917 in run_actions (h=0x7ffd364bd680, a=0x7fd919e199c0, msg=0x7fd919efeb70) at action.c:1548 #33 0x000000000041e112 in do_action (h=0x7ffd364bd680, a=0x7fd919e19b08, msg=0x7fd919efeb70) at action.c:1048 #34 0x000000000042a917 in run_actions (h=0x7ffd364bd680, a=0x7fd919df99d8, msg=0x7fd919efeb70) at action.c:1548 #35 0x000000000041ab46 in do_action (h=0x7ffd364bd680, a=0x7fd919dbe960, msg=0x7fd919efeb70) at action.c:677 #36 0x000000000042a917 in run_actions (h=0x7ffd364bd680, a=0x7fd919daedf8, msg=0x7fd919efeb70) at action.c:1548 #37 0x000000000042b07d in run_top_route (a=0x7fd919daedf8, msg=0x7fd919efeb70, c=0x0) at action.c:1634 #38 0x000000000050f678 in receive_msg (buf=0x7fd8f2c6ce28 "SUBSCRIBE sip:endpoint-1720@intouchstaging.com SIP/2.0\r\nRecord-Route: <sip:64.64.203.109:443;transport=tls;lr=on>\r\nAccept: application/dialog-info+xml, application/pidf+xml, application/pidf-diff+xml,"..., len=1284, rcv_info=0x7fd8f2c6cb50) at receive.c:196 #39 0x00000000005fb99e in receive_tcp_msg (tcpbuf=0x7fd8f2c6ce28 "SUBSCRIBE sip:endpoint-1720@intouchstaging.com SIP/2.0\r\nRecord-Route: <sip:64.64.203.109:443;transport=tls;lr=on>\r\nAccept: application/dialog-info+xml, application/pidf+xml, application/pidf-diff+xml,"..., len=1284, rcv_info=0x7fd8f2c6cb50, con=0x7fd8f2c6cb38) at tcp_read.c:1207 #40 0x00000000005fd48c in tcp_read_req (con=0x7fd8f2c6cb38, bytes_read=0x7ffd364bdb7c, read_flags=0x7ffd364bdb84) at tcp_read.c:1411 #41 0x0000000000600aee in handle_io (fm=0x7fd919f07d80, events=1, idx=-1) at tcp_read.c:1643 #42 0x00000000005f3ab8 in io_wait_loop_epoll (h=0xa3d3e0 <io_w>, t=2, repeat=0) at io_wait.h:1061 #43 0x0000000000601cf7 in tcp_receive_loop (unix_sock=57) at tcp_read.c:1755 #44 0x00000000005ea235 in tcp_init_children () at tcp_main.c:4788 #45 0x00000000004ab048 in main_loop () at main.c:1675 #46 0x00000000004b10c2 in main (argc=13, argv=0x7ffd364be258) at main.c:2566 --------- Thanks very much. -Cody

2 8

Issue with ims_isc module? (distinct PSI)
by Valentin Christoph 02 Aug '17

02 Aug '17

Hi, Can anyone comment on issue #1168? https://github.com/kamailio/kamailio/issues/1168 Thanks, Christoph The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.

3 3

Kamailio CDR "best practices"
by Yu Boot 02 Aug '17

02 Aug '17

How to make Kamailio write "normal" CDRs? acc cdr module writes start time and end time in unixtime format, that is very uncomfortable. Fnd stcond question - how to make Kamailio to write CDR in ordinary text file?

2 3

Usleep on Reply
by Nicolas Breuer 01 Aug '17

01 Aug '17

Hello All, I'm trying to code something on the on_reply part to do something if I receive a 183 ( Session in progress ) , followed immediately by a "180" I tried to sleep 1 second the 183 and recheck if I received before a 180 but seems the "sleep" function sleeps everything ( also the received 180 ) Is a developper can confirm that ? The goal is to detect if a 180 follow the 183.

3 4

Getting Error - error reading: Connection reset by peer (104)
by Prem Kumar N 01 Aug '17

01 Aug '17

Hi All, I have a setup with two kamailio v5.0 and a load balancer(keepalived) It seems to check the heath of kamailio server load balancer establishing the tcp conneciton and resetting the connection once its got established. and due to resetting the connection I keep on getting following log message. Jul 31 18:14:18 localhost /usr/local/kamailio/sbin/kamailio[9388]: ERROR: <core> [core/tcp_read.c:291]: tcp_read_data(): error reading: Connection reset by peer (104) ([192.168.xxx.xxx]:46574 -> Jul 31 18:14:18 localhost /usr/local/kamailio/sbin/kamailio[9388]: ERROR: <core> [core/tcp_read.c:292]: tcp_read_data(): -> [192.168.yyy.yyy]:443) Jul 31 18:14:18 localhost /usr/local/kamailio/sbin/kamailio[9388]: ERROR: <core> [core/tcp_read.c:1319]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f6547989e78 r: 0x7f6547989ef8 Jul 31 18:14:18 localhost /usr/local/kamailio/sbin/kamailio[9389]: ERROR: <core> [core/tcp_read.c:291]: tcp_read_data(): error reading: Connection reset by peer (104) ([192.168.xxx.xxx]:44279 -> Jul 31 18:14:18 localhost /usr/local/kamailio/sbin/kamailio[9389]: ERROR: <core> [core/tcp_read.c:292]: tcp_read_data(): -> [192.168.yyy.yyy]:5060) Jul 31 18:14:18 localhost /usr/local/kamailio/sbin/kamailio[9389]: ERROR: <core> [core/tcp_read.c:1319]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f6547989e78 r: 0x7f6547989ef If any one can suggest, how can i get rid of these logs. Thanks Prem

2 2

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users July 2017