sr-users February 2016

sr-users@lists.kamailio.org

80 participants
132 discussions

Kamailio on Mac
by Carlos Ruiz Díaz 04 Aug '16

04 Aug '16

Hi all, I'm switching my development environment from Linux to Mac. Is there any tutorial on how to setup Kamailio on this OS? It may be an Unix flavor, but it's still quite different from Linux :). Thanks, -- Carlos http://caruizdiaz.com http://ngvoice.com +52 55 3048 3303

6 9

Sipcapture on SPARC
by Spencer Thomason 18 May '16

18 May '16

Hello, I’m attempting to deploy a homer sip capture server on SPARC and I’m seeing some strange date related errors: ERROR: db_mysql [km_dbase.c:128]: db_mysql_submit_query(): driver error on query: Incorrect datetime value: '2052-06-12 16:21:06' for column 'date' at row 1 (1292) Is there some sore of endianness issue? Thanks for any assistance! Regards, Spencer

2 3

sdp_remove_line_by_prefix
by Alberto Sagredo 09 May '16

09 May '16

Hi Im trying to remove my Asterisk s= line on SDP but when doing: sdp_remove_line_by_prefix("s=Asterisk"); Nothing happens. Loaded sdpops.so module as well. Is there any additional needed? BR

4 10

t_on_branch_failure never called AND t_relay never fails in a, forked scenario
by Tristan Mahé 03 May '16

03 May '16

Hi fellow kamailio users, I'm playing actually with t_on_branch_failure, in a simultaneous forking scenario ( lookup("location") returns multiple contacts ). Any idea on how to get those "on_branch_failure" working ? Thanks in Advance ! * Test by putting failure_exec_mode: - at 1 => no branch failure being called, never. - at 0 => t_relay does not fail if a single branch answers the transaction, even if all other branches are failing. * Test by moving the t_on_branch_failure("manage_branch_failure"); line before or after the lookup("location") or on a _on_branch route to set it per branch. - The on_route branch are executed, but never the failure one. - tried also with failure_exec_mode = 0 or 1. * Using set_forward_no_connect, I can see in the logs a "Sending to branch X failed" but no failure route being executed. Without it, nothing in the logs indicating that the branch has timeout. * Config extract: # auto-discard branches from previous serial forking leg modparam("tm", "failure_reply_mode", 3) # 3 by default # default retransmission timeout: 30sec modparam("tm", "fr_timer", 30000) # default invite retransmission timeout after 1xx: 120sec modparam("tm", "fr_inv_timer", 120000) modparam("tm", "reparse_on_dns_failover", 0) # 1: Allow branches to have a per branch failure route # 0: t_relay should fail if a branch fail modparam("tm", "failure_exec_mode", 1) # Allow locally generated 408 to be forgotten in case a reply is received. #modparam("tm", "faked_reply_prio", 2000) # USER location service route[LOCATION] { t_on_branch_failure("manage_branch_failure"); if (!lookup("location")) { .... } # Let's get back after 2.5s if no 100/Trying received. t_set_fr(0, 2500); # set_forward_no_connect(); #t_on_branch("SET_BRANCH_FAILURE"); route(RELAY); exit; } route[RELAY] { .... if (!t_relay()) { xlog("L_WARN","$rm|$ci|$fu|$tu|RELAY_FAILED"); sl_reply_error(); } exit(); } # set failure route per branch branch_route[SET_BRANCH_FAILURE] { xlog("L_WARN","$rm|$ci|$fu|$tu|SETTING_BrANCH_FAILURE_ROUTE"); t_on_branch_failure("manage_branch_failure"); } # manage failure routing cases per branch event_route[tm:branch-failure:manage_branch_failure] { xlog("L_WARN","$rm|$ci|$fu|$tu[$avp(dest_to)]|MANAGE_BRANCH_FAILURE"); }

3 2

Trouble initializing TLS on Fedora 23
by Anthony Messina 02 Apr '16

02 Apr '16

Happy New Year! I've just upgraded my Kamailio (build from master@c7e411e) instance to Fedora 23 from Fedora 22. I've built the packages specifically for Fedora 23 with the following current sources: openssl-1.0.2e-3.fc23.x86_64 openssl-libs-1.0.2e-3.fc23.x86_64 openssl version reports... OpenSSL 1.0.2e-fips 3 Dec 2015 Even so, the following error occurs. It seems like Kamailio having trouble detecting that I'm using running with the same version that I have installed, and the same version that I have compiled against. tls [tls_init.c:557]: init_tls_h(): ERROR: tls: init_tls_h: installed openssl library version is too different from the library the Kamailio tls module was compiled with: installed "OpenSSL 1.0.0-fips 29 Mar 2010" (0x10000003), compiled "OpenSSL 1.0.2d-fips 9 Jul 2015" (0x1000204f). Please make sure a compatible version is used (tls_force_run in kamailio.cfg will override this check) CRITICAL: <core> [main.c:2558]: main(): could not initialize tls, exiting... Any pointers? -A -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E

3 7

Record-Route header
by jignesh gandhi 01 Apr '16

01 Apr '16

Hello All, I have a need to save the Record-Route header from the INVITE and use it as a route header in requests like BYE. PROXY --> Kamailio(as PROXY) --> Asterisk I am using rr module to add a record_route when passing the INVITE to Asterisk. Thanks, Jignesh Gandhi

2 4

kamailio in a multi-site configuration
by Sébastien Brice 24 Mar '16

24 Mar '16

Hi everyone i am installing Kamailio to scale asterisk on a remote hosted server in a way to manage calls dialogs in a real-time fashion. (and to manage many customers) Several users (maybe 80) are working at the head-office and i want them register their hardphone on the remote Kamailio Ipbx, to free them of ours end-of-life PABX (alcatel-Lucent). Can kamailio help me to achieve that ? What kind of software have I to install locally (mysql to replicate the master mysql db? a replicated asterisk instance?) ? Taking into consideration disaster recovery plan What could be my options to maintain internal call if my internet provider get down by exemple. thx you for your idea. Sébastien BRICE VoIP, Support et Intégration

3 2

Re: [SR-Users] Registration Failure - IMS
by Franz Edler 11 Mar '16

11 Mar '16

Hi Cristina, > But I have another problem related to registration process. After REGISTER- > 401 Unauthorized-REGISTER-200 OK, the IMS client sends the SUBSCRIBE > message (for the "reg" event package subscription) to the S-CSCF, the latter > replies with NOTIFY and the client correctly responds with 200 OK. In order to > be notified on any change of registration state for the client, also the P-CSCF > sends the SUBSCRIBE message to the S-CSCF, the S-CSCF sends a NOTIFY to > the proxy but, instead of replying with 200 OK, the P-CSCF replies with 404- > Not Here (like it doesn't recognize that the recipient of the NOTIFY in the > Req-URI is the P-CSCF itself). > > Have you ever seen similar issue? I have now spent some time to reproduce the issue. First of all: I had to adapt module reg_mod.c in ims_registrar_pcscf, because it containes a hardcoded P-CSCF address: str pcscf_uri = str_init("sip:pcscf.ims.smilecoms.com:4060"); which is only valid for smilecoms. Did you also change that? Then I got exactly the same problem. I found that the P-CSCF config causes in the part "# Check for Subsequent requests:" a reject " sl_send_reply("404","Not here");" I have doubts that this is correctly designed and have to dig deeper into the logic of the config-file. Fact is: the NOTIFY request does not contain a Route header and as it not an ACK it goes straight to the reject. Maybe any IMS expert can shed some light on this code as shown below: # Check for Subsequent requests: if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if ($route_uri =~ "sip:mo@.*") { setflag(FLT_MO); } if(!isdsturiset()) { handle_ruri_alias(); } # RTP-Relay, if necessary route(RTPPROXY); t_relay(); } else { if ( is_method("ACK") ) { if ( t_check_trans() ) { # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction ... ignore and discard exit; } } sl_send_reply("404","Not here"); } exit; BR Franz

3 3

UDP send: Operation not permitted
by Sebastian Damm 11 Mar '16

11 Mar '16

Hi, we have a load balancer which is handling a lot of SIP traffic all day. There's always 20-40 Mbit SIP traffic going through. From time to time we see in our logs messages like these: Sep 16 09:46:28 ecker /usr/sbin/kamailio[25505]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7f2d9d6b3ce0,1321,0,46.237.225.126:5060,16): Operation not permitted(1) Sep 16 09:46:38 ecker /usr/sbin/kamailio[25194]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7efc982b8fc8,420,0,82.113.121.183:35794,16): Operation not permitted(1) Sep 16 09:46:40 ecker /usr/sbin/kamailio[25505]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7f2d9d6b3ce0,1338,0,5.158.137.9:55067,16): Operation not permitted(1) Sep 16 09:46:44 ecker /usr/sbin/kamailio[25183]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7efc982d9f48,450,0,178.165.131.197:37515,16): Operation not permitted(1) Sep 16 09:46:49 ecker /usr/sbin/kamailio[25643]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7f93fb624530,496,0,172.56.7.69:25643,16): Operation not permitted(1) Sep 16 09:46:55 ecker /usr/sbin/kamailio[25335]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7f41632cda98,598,0,80.215.234.139:3396,16): Operation not permitted(1) Sep 16 09:46:56 ecker /usr/sbin/kamailio[25345]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7f41632f4840,459,0,94.197.120.191:8225,16): Operation not permitted(1) I know that these messages can be produced by iptables blocking the outbound traffic. But our outbound chain looks basically like this: root@ecker:~# iptables-save | grep OUTPUT :OUTPUT DROP [0:0] -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -j ACCEPT -A OUTPUT -m state --state INVALID -j DROP -A OUTPUT -o lo -m state --state NEW -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -m state --state NEW -j ACCEPT We don't have the nf_ct_sip module loaded, syslog doesn't say anything, and even clearing all iptables rules doesn't eliminate those errors. Has anyone ever seen this? It looks like a load thing, because at weekends there are significantly less errors. Thanks, Sebastian

5 7

rare impossibility to send requests to TLS connected peer
by Vasiliy Ganchev 09 Mar '16

09 Mar '16

Hi folk! Have a rare issue with tls connections. Have a server with 100+ active tls connections, that are connected to separate TCP proxy, that listen on port 443. TCP proxy send sip traffic to Kamailio via localhost:5061. In this way all connections in Kamailio are considered from Localhost. Issue scheme: - UA-A (sip-phone, UDP/TCP/TLS) -> call -> sip server (Kamailio+Asterisk based) -> UA-B (sip phone, transport=TLS) - The troubles happened in part of flow to UA-B: --- kamailio script make lookup(location), find AOR for UA-B (here is OK) --- after t_relay, kamailio make branch_route logic and try to send INVITE to tcp socket --- HERE IS the trouble: connection seems to be opened, but Kamailio cannot send INVITE there (say: no open tcp connection found) --- Kamailio try to open tcp connection from itself, TCP proxy refuse it --- as a result - Kamailio answer 477 to Asterisk, and finish processing debug level 3 logs (from the point where Kamailio try to send INVITE in opened connection) Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1463]: _tcpconn_find(): tcpconn_find: 0 port 60286 Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [ip_addr.c:243]: print_ip(): tcpconn_find: ip 127.0.0.1 Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1820]: tcp_send(): tcp_send: no open tcp connection found, opening new one Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: 127.0.0.1 Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 60286, type 3 Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1626]: _tcpconn_add_alias_unsafe(): _tcpconn_add_alias_unsafe: alias port 60286 for hash 2646, id 404319 Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1626]: _tcpconn_add_alias_unsafe(): _tcpconn_add_alias_unsafe: alias port 60286 for hash 2728, id 404319 Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1624]: _tcpconn_add_alias_unsafe(): _tcpconn_add_alias_unsafe: alias already present Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 2646:2728:0, 863 Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tls [tls_server.c:184]: tls_complete_init(): Using TLS domain TLSc<default> Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tls [tls_domain.c:700]: sr_ssl_ctx_info_callback(): SSL handshake started Jan 25 14:32:43 /usr/sbin/kamailio[4722]: ERROR: <core> [tcp_main.c:2742]: tcpconn_1st_send(): connect 127.0.0.1:60286 failed (RST) Connection refused Jan 25 14:32:43 /usr/sbin/kamailio[4722]: ERROR: <core> [tcp_main.c:2752]: tcpconn_1st_send(): 127.0.0.1:60286: connect & send for 0xb1d3b7e8 failed: Connection refused (111) Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [tcp_main.c:2947]: tcpconn_chld_put(): tcpconn_chld_put: destroying connection 0xb1d3b7e8 (404319, -1) flags 0060 Jan 25 14:32:43 /usr/sbin/kamailio[4722]: ERROR: tm [../../forward.h:247]: msg_send(): tcp_send failed Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_fwd.c:1591]: t_send_branch(): t_send_branch: send to 127.0.0.1:60286 (3) failed Jan 25 14:32:43 /usr/sbin/kamailio[4722]: WARNING: tm [t_fwd.c:1610]: t_send_branch(): ERROR: t_send_branch: sending request on branch 0 failed Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_funcs.c:358]: t_relay_to(): ERROR:tm:t_relay_to: t_forward_nonack returned error Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_funcs.c:375]: t_relay_to(): -477 error reply generation delayed Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_lookup.c:1526]: t_unref(): t_unref: delayed error reply generation(-477) Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: <core> [parser/msg_parser.c:339]: parse_headers(): parse_headers: flags=ffffffffffffffff Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_reply.c:1670]: cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers reset Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_reply.c:728]: _reply_light(): DEBUG: reply sent out. buf=0xb67c000c: SIP/2.0 477 Unfortun..., shmem=0xb1b676cc: SIP/2.0 477 Unfortun Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_funcs.c:156]: put_on_wait(): DEBUG: put on WAIT Jan 25 14:32:43 /usr/sbin/kamailio[4722]: DEBUG: tm [t_reply.c:738]: _reply_light(): DEBUG: _reply_light: finished Additionally want to say, that suddenly we don't have clear reproduce, it happened only on 2 production servers, what are common conditions for issue: - transport=TLS - when issued call is done, I checked with netstat, the connection is alive - the issued device is re-REGISTERed as usual, in kamctl ul show I see registration before/during/after issued call - issue appear only when connection through our custom TCP proxy :443 (to Kamailio it is from 127.0.0.1:5061) - if connection switched to Kamailio 5061 directly - issue never (till now) reproduced - in one of the issued server - I noticed big number of tcp id. Doing kamcmd core.tcp_list, I saw e.g. id: 567852 (usually id numbers are not more than 1000). - if kamailio/device reboot - problem disappear Because of not completely understanding how tcp core is working in kamailio, ask any suggestion, why such could happen. Any idea/hints would be greatly appreciated! kamailio -v version: kamailio 4.2.5 (i386/linux) flags: STATS: Off, EXTRA_DEBUG, USE_TCP, USE_TLS, 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: unknown compiled on 16:03:38 Jan 12 2016 with gcc 4.3.2 sorry for the long description cheers! -- View this message in context: http://sip-router.1086192.n5.nabble.com/rare-impossibility-to-send-requests… Sent from the Users mailing list archive at Nabble.com.

2 5

Jump to page:

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 February 2016