Thanks for the link.
One issue I've noticed:
If you have an empty comment line (just # on a single line), then the next line is wrongly highlighted as comments.
For example:
#
loadmodule "db_postgres.so"
> i'm using https://github.com/miconda/vscode-kamailio-syntax in VScode.
> its great!
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Hi,
I am having a problem on fail overing my master kamailio server and slave
kamailio server.
I use kamailio as a load balancer for my asterisk servers. And it is
working with calls, but when I added failover with keepalived to the slave,
there is no audio during calls.
Thank you,
Rolly
Hello,
I have a kamailio server running behind HAProxy with proxy protocol v2 enabled.
In Kamailio I have set the parameter tcp_accept_haproxy=yes and loaded tcpops module.
UEs are registered using TLS and kamailio sees that the message has received from their real ip address + port and not HAProxy ip + port.
When UE A calls UE B, kamailio is trying to reach UE B using his real ip address and port instead of HAProxy IP address + port.
I know I can get the tcp ip and port of HAProxy using $tcp(c_si) and $tcp(c_sp) but I can’t make it work.
What is the right way to do this? How should I use these variables properly in order to establish the call successfully?
Thanks,
Joey.
Greetings,
I'm having a "fun" time trying to run Kamailio inside a Docker container.
It keeps failing with:
0(238) DEBUG: <core> [core/mem/pkg.c:108]: pkg_print_manager(): pkg -
using memory manager: q_malloc
0(238) DEBUG: <core> [core/mem/shm.c:300]: shm_print_manager(): shm -
using memory manager: q_malloc
Illegal instruction (core dumped)
Unfortunately the core dump is nowhere to be found. I have tried to follow
the instructions at:
https://www.kamailio.org/wiki/tutorials/troubleshooting/coredumpfile
but that hasn't helped.
The environment is as follows:
* Host hardware: Raspberry Pi 4 (4G memory)
* Host OS: Ubuntu 20.04.1 LTS
* Docker version 19.03.13
* Docker base image: arm32v7/ubuntu
root@2ef8a21534fa:/# kamailio -v
version: kamailio 5.3.2 (arm/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE,
USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC,
TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT-NOSMP,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, 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 with gcc 9.2.1
The config file passes the syntax check:
kamailio -c -f /etc/kamailio/kamailio.cfg
and, the most interesting part, if I run Kamailio on the host machine,
_with the exact same config file_, it runs fine.
I'd appreciate any clues you may have. Thanks.
cv
Hi,
What is the lifecycle of Branch Flag? If its set in Request Route will it be available till end of Dialog or It will be available during Transaction only ?
Thanks
Dear Users
I have been facing a diameter peer disconnection issue between I-CSCF and HSS. after taking traces on both sides, I saw a lot of TCP Zero Window packets from HSS towards I-CSCF and after that HSS disconnects with the following errors in the log.
Nov 26 20:30:25 PROD-HSS-STANDBY [HSS][16401]: ERROR: cdp [peerstatemachine.c:157]: sm_process(): sm_process(): In state Closed invalid event Timeout
Nov 26 20:31:25 PROD-HSS-STANDBY [HSS][16401]: ERROR: cdp [peerstatemachine.c:157]: sm_process(): sm_process(): In state Closed invalid event Timeout
Nov 26 20:32:25 PROD-HSS-STANDBY [HSS][16401]: ERROR: cdp [peerstatemachine.c:157]: sm_process(): sm_process(): In state Closed invalid event Timeout
Nov 26 20:33:04 PROD-HSS-STANDBY systemd[1]: Stopping LSB: Start the Kamailio SIP proxy server...
Nov 26 20:33:04 PROD-HSS-STANDBY kamailio_hss[18098]: Stopping Kamailio SIP Server: kamailio_hss:.
Nov 26 20:33:04 PROD-HSS-STANDBY systemd[1]: kamailio_hss.service: Succeeded.
Nov 26 20:33:04 PROD-HSS-STANDBY systemd[1]: Stopped LSB: Start the Kamailio SIP proxy server.
Nov 26 20:33:04 PROD-HSS-STANDBY [HSS][16274]: CRITICAL: cdp [diameter_peer.c:423]: diameter_peer_destroy(): destroy_diameter_peer(): Bye Bye from C Diameter Peer test
Nov 26 20:33:07 PROD-HSS-STANDBY systemd[1]: Starting LSB: Start the Kamailio SIP proxy server...
Nov 26 20:33:07 PROD-HSS-STANDBY kamailio_hss[18138]: Starting Kamailio SIP Server: kamailio_hss:loading modules under config path: /usr/local/lib64/kamailio/modules/:/usr/lib64/kamailio/modules_k/:/usr/lib64/kamailio/modules/:/usr/local/lib/kamailio/modules/
Nov 26 20:33:07 PROD-HSS-STANDBY kamailio_hss[18138]: Listening on
Nov 26 20:33:07 PROD-HSS-STANDBY kamailio_hss[18138]: udp: 10.161.224.81 [10.161.224.81]:8080
Nov 26 20:33:07 PROD-HSS-STANDBY kamailio_hss[18138]: tcp: 127.0.0.1 [127.0.0.1]:5090
Nov 26 20:33:07 PROD-HSS-STANDBY kamailio_hss[18138]: tcp: 10.161.224.81 [10.161.224.81]:8080
Nov 26 20:33:07 PROD-HSS-STANDBY kamailio_hss[18138]: Aliases:
Nov 26 20:33:07 PROD-HSS-STANDBY [HSS][18155]: WARNING: sl [../../modules/tm/tm_load.h:149]: load_tm_api(): Cannot import load_tm function from tm module
Nov 26 20:33:07 PROD-HSS-STANDBY [HSS][18155]: WARNING: sl [../../modules/tm/tm_load.h:149]: load_tm_api(): Cannot import load_tm function from tm module
Nov 26 20:33:07 PROD-HSS-STANDBY [HSS][18281]: WARNING: cdp [tcp_accept.c:120]: create_socket(): create_socket(): Trying to open/bind/listen on 10.161.224.81 port 3868
Nov 26 20:33:07 PROD-HSS-STANDBY [HSS][18281]: WARNING: cdp [tcp_accept.c:145]: create_socket(): create_socket(): Successful socket open/bind/listen on 10.161.224.81 port 3868
Nov 26 20:33:07 PROD-HSS-STANDBY kamailio_hss[18138]: .
Nov 26 20:33:07 PROD-HSS-STANDBY systemd[1]: Started LSB: Start the Kamailio SIP proxy server.
Nov 26 20:38:44 PROD-HSS-STANDBY [HSS][18282]: WARNING: cdp [peermanager.c:310]: peer_timer(): Inactivity on peer [icscfcdp2.ims.mnc006.mcc410.3gppnetwork.org] and no DWA, Closing peer...
Nov 26 20:39:01 PROD-HSS-STANDBY systemd[1]: Starting Clean php session files...
Nov 26 20:39:01 PROD-HSS-STANDBY systemd[1]: phpsessionclean.service: Succeeded.
Nov 26 20:39:01 PROD-HSS-STANDBY systemd[1]: Started Clean php session files.
Nov 26 20:39:20 PROD-HSS-STANDBY [HSS][18282]: ERROR: cdp [peerstatemachine.c:157]: sm_process(): sm_process(): In state Closed invalid event Timeout
I am using the following Kamailio version
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
Version: kamailio 5.2.8 (x86_64/linux) 5a7f5b
Default config: /usr/local/etc/kamailio/kamailio.cfg
Default paths to modules: /usr/local/lib64/kamailio/modules
Compile 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, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
MAX_RECV_BUFFER_SIZE=262144
MAX_URI_SIZE=1024
BUF_SIZE=65535
DEFAULT PKG_SIZE=8MB
DEFAULT SHM_SIZE=64MB
ADAPTIVE_WAIT_LOOPS=1024
TCP poll methods: poll, epoll_lt, epoll_et, sigio_rt, select
Source code revision ID: 5a7f5b
Compiled with: gcc 8.3.0
Compiled on: 04:34:39 Nov 19 2020
How I can resolve TCP Zero Window Error? I have already tried increasing CDP worker threads, TCP read and write buffers etc.
Regards
Hamid R. Hashmi
Hello,
I want to ask for your opinion on the best approach regarding the handling of locally generated 478 errors.
To give an example, like the ones generated from TM during t_relay() on an unresolvable destination.
Nov 25 17:40:13 kamailio[19345]: ERROR: {28607414 INVITE bba500ac-a9df-1239-6693-00505682c04d} tm [ut.h:286]: uri2dst2(): failed to resolve "invalid.skalatan.de" :unresolvable A or AAAA request (-7)
Nov 25 17:40:13 kamailio[19345]: ERROR: {28607414 INVITE bba500ac-a9df-1239-6693-00505682c04d} tm [t_fwd.c:1738]: t_forward_nonack(): failure to add branches
Nov 25 17:40:13 kamailio[19345]: CRITICAL: {28607414 INVITE bba500ac-a9df-1239-6693-00505682c04d} rtpengine [../../core/parser/../ip_addr.h:658]: ip_addr2sbuf(): unknown address family 0
These errors will not show up in onreply or failure_route. A long time ago this was discussed on the list [1], as some functionality were phased out out that support these scenarios.
Kamailio will try to generate a 478 with TM, this will obviously fail as well, and then generate a 478 with SL.
Question 1)
Is this intentional that the internally generated 478 is not showing up in the failure_route, like for for 408? This has been tested several times, but it is a complicated configuration.
Question 2)
Are there any other (better) ideas how to handle that besides using a "event_route[sl:local-response]" to catch this, e.g. to tear down otherwise stale rtpengine sessions etc..? As a side note, event_route[tm:local-response] seems not to work as well because of the tm failure.
Thanks,
Henning
[1] https://lists.kamailio.org/pipermail/sr-users/2011-June/069020.html
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com<https://gilawa.com/>
Greetings ,
i am around to setup an IMS solution based on your Kamailio solution
however i cant find a clear guide to dit properly.
I am seeking by this mail you guide to could achieve my setup
Thanks and BR,
Adnen
Dear all
We are trying to use the evapi module to send some data to an external
application but I'm having problems getting the clients connected.
I have the kamailio (version 5.3) running with a tcp socket 127.0.0.1:8228,
and the evapi params are just
modparam("evapi", "workers", 4)
modparam("evapi", "netstring_format", 0)
modparam("evapi", "bind_addr", "127.0.0.1:8448")
modparam("evapi", "max_clients", 32)
I tried a different number of workers and netstring_format 1 too.
When I start the kamailio i added some debug to the code, and seems when
doing the mod init of the evapi dispatcher
38(4779) DEBUG: <core> [core/sr_module.c:779]: init_mod_child(): idx 38
rank -2: evapi [EvAPI Dispatcher]
it reaches to
while(1) {
ev_loop (loop, 0);
}
at evapi_run_dispatcher function.
I guess if I connected to the tcp socket and sent some event, I would see
the client accepted and the event route evapi:connection-new would be
triggered. But i'm not able to do that.
I tried to use the prime option, a tcp input client connection from
logstash, so i could relay the data to the logstash using the evapi relay,
but i only see the tcp socket being created but no client accepted.
I also tried to connect with an erlang gen_tcp client, but it's the same
i only see
47(4798) DEBUG: <core> [core/ip_addr.c:229]: print_ip(): tcpconn_new: new
tcp connection: 127.0.0.1
47(4798) DEBUG: <core> [core/tcp_main.c:1174]: tcpconn_new(): on port
54537, type 2, socket 105
47(4798) DEBUG: <core> [core/tcp_main.c:1497]: tcpconn_add(): hashes:
1117:1187:1505, 1
47(4798) DEBUG: <core> [core/io_wait.h:375]: io_watch_add(): DBG:
io_watch_add(0xad0880, 105, 2, 0x7fc211712d58), fd_no=53
and if i try to send any data
47(4798) DEBUG: <core> [core/io_wait.h:600]: io_watch_del(): DBG:
io_watch_del (0xad0880, 105, -1, 0x0) fd_no=54 called
47(4798) DEBUG: <core> [core/tcp_main.c:4456]: handle_tcpconn_ev(): sending
to child, events 1
47(4798) DEBUG: <core> [core/tcp_main.c:4129]: send2child(): selected tcp
worker idx:0 proc:43 pid:4791 for activity on [tcp:127.0.0.1:8448],
0x7fc211712d58
43(4791) DEBUG: <core> [core/tcp_read.c:1749]: handle_io(): received n=8
con=0x7fc211712d58, fd=39
43(4791) DEBUG: <core> [core/io_wait.h:375]: io_watch_add(): DBG:
io_watch_add(0xb3c720, 39, 2, 0x7fc211712d58), fd_no=1
43(4791) DEBUG: <core> [core/io_wait.h:600]: io_watch_del(): DBG:
io_watch_del (0xb3c720, 39, -1, 0x10) fd_no=2 called
43(4791) DEBUG: <core> [core/tcp_read.c:1671]: release_tcpconn(): releasing
con 0x7fc211712d58, state 1, fd=39, id=1 ([127.0.0.1]:54537 ->
[127.0.0.1]:8448)
43(4791) DEBUG: <core> [core/tcp_read.c:1672]: release_tcpconn():
extra_data (nil)
47(4798) DEBUG: <core> [core/tcp_main.c:3559]: handle_tcp_child(): reader
response= 7fc211712d58, 1 from 0
47(4798) DEBUG: <core> [core/io_wait.h:375]: io_watch_add(): DBG:
io_watch_add(0xad0880, 105, 2, 0x7fc211712d58), fd_no=53
47(4798) DEBUG: <core> [core/tcp_main.c:3686]: handle_tcp_child():
CONN_RELEASE 0x7fc211712d58 refcnt= 1
and when i try to send any data
38(10867) DEBUG: evapi [evapi_dispatch.c:610]: evapi_recv_notify():
received [0x7f17d23fc628] [{"test" : "1.1.1.1", "uuid" : "1-31629(a)3.3.3.3"
, "pdd" : "4"}] (75)
38(10867) DEBUG: evapi [evapi_dispatch.c:316]: evapi_dispatch_notify(): the
message was sent to 0 clients
I don't know what i'm missing, or if i'm understanding the use of the
module correctly
could you please take a look?
thanks a lot
David
--
[image: Logo]
David Escartín Almudévar
VoIP/Switch Engineer
descartin(a)sonoc.io
*SONOC*
C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España
Tlf: +34 917019888 · www.sonoc.io
On a usrloc record there is an Address field and Received field. The
Received field is sometimes not set. What causes it to be not set and what
is the difference between the two fields. Sorry if this is a dumb question,
I looked at documentation but couldn't find it spelled out. Here is are 2
examples from kamcmd ul.dump:
{
AoR: utkcf9b6h3(a)ata.phaxio.com
Contacts: {
Contact: {
Address: sip:utkc4ff9b6h3@69.78.34.56:4615;transport=tcp
Expires: 42
Q: -1.000000
Call-ID: d1c314305df3d342(a)192.168.0.3
CSeq: 129173
User-Agent: OBIHAI/OBi200-3.2.2.5898
Received: [not set]
Path: [not set]
State: CS_NEW
Flags: 0
CFlags: 0
Socket: tcp:10.0.22.254:5060
Methods: 7839
Ruid: uloc-5fbdd369-491e-4
Instance:
<urn:uuid:00000000-0000-0000-0000-9cadef62b3da>
Reg-Id: 0
Server-Id: 0
Tcpconn-Id: 58
Keepalive: 0
Last-Keepalive: 1606317577
Last-Modified: 1606317577
}
}
}
Contact: {
Address: sip:mfjngfd272av@192.168.0.106:5060
Expires: 30
Q: -1.000000
Call-ID: 67413de375b2e76c(a)192.168.0.106
CSeq: 146320
User-Agent: OBIHAI/OBi300-3.2.2.5921
Received: sip:70.34.56.78:5060
Path: [not set]
State: CS_NEW
Flags: 0
CFlags: 64
Socket: udp:10.0.22.254:5060
Methods: 7839
Ruid: uloc-5fbdd369-490e-efa3
Instance: <urn:uuid:00000000-0000-0000-0000-9cadef810877>
Reg-Id: 0
Server-Id: 0
Tcpconn-Id: -1
Keepalive: 1
Last-Keepalive: 1606314719
Last-Modified: 1606314719
}
