I have kamailio behind a TLS termination proxy so the sockets are correctly
deduced to be TCP. However the clients only talk TLS to the proxy and are
confused when the top Via header added by Kamailio is TCP. Is there a way
for Kamailio to forcibly pretend its protocol is TLS? Like
advertised_address but "advertised_protocol" instead.
(With pjsip testing: it has a flag use_tls which ignores TCP from Kamailio
and continues to use the persistent TLS transport to proxy. Linphone fails
because it tries to honor TCP in Via and is unable to establish TCP
transport).
BTW I am using t_relay_to_tcp so Kamailio will return traffic to the proxy
as TCP even though the contact addresses specify transport=TLS.
Hi everybody,
I'm just testing Kamailio 5.4.1 with dialog replication over DMQ. This
seems to work very good. Dialogs are replicated without problems.
When I'm restarting one node I would have expected, that all dialogs are
synced again, just like in dmq_usrloc.
But this does not happen. After a restart the nodes dialog-list is empty.
Did I miss somethin? Is there a special parameter that I have to set?
BR, Björn
--
Björn Klasen, Specialist
TNG Stadtnetz GmbH, Network Management (VoIP)
Projensdorfer Straße 324
24106 Kiel
Germany
T +49 431/ 530530
F +49 431/ 7097-555
mailto: bklasen(a)tng.de
http://www.tng.de
Register: Amtsgericht Kiel HRB 6002 KI
Executive board (Geschäftsführung): Dr.-Ing. Volkmar Hausberg,
Sven Schade, Carsten Tolkmit, Dr. Sven Willert
Tax-Id (Steuernr.): 2029047020, VAT-Id (USt-Id): DE225201428
Hi,
I am building a configuration script where for some traffic flows
parallel forking will be needed, and in this case I need to go beyond
the default max limit of the max amount of branches.
Apart from this specific case the traffic load that kamailio will need
to handle is very low, let's say just one second here and there with up
to 5 concurrent calls at most.
This limit is as far as I understand set here:
usr/local/src/kamailio-5.6/kamailio/src/core/config.h
And the default limit is:
#define MAX_BRANCHES_LIMIT 32 /*!< limit of maximum
number of branches per transaction */
Here are the questions I have related to this:
1) If I increase the value of this constant in config.h, how high is it
reasonable to set this value and still have a stable system?
2) If I increase MAX_BRANCHES_LIMIT beyond 32, are there also other
parameters that needs to be changed for the system to be able to cope,
and if so whichparameters?
Regards,
Lars
Hi All,
I am facing an issue in understanding how the min_se should be working in
kamailio. As per the SST documentation, it seems like if the min_se is
configured as 500, then any value of Session-Expires OR MIN-SE if lower
than 500, can be responded to by a 422.
However, I strangely see the reverse happening. To investigate further, I
looked in to the ki_sst_check_min() code in the master, and these seems
like a potential issue.
Ref Code: Inside ki_sst_check_min(), there is an if condition like below:
if (sst_min_se < MIN(minse, se.interval)) {
However, shouldn't it be the other way around? ie
if (sst_min_se > MIN(minse, se.interval)) {
because we need to send 422 if the received value(in INVITE etc) is
smaller than the sst configure min_se value?
I also found a different documentation, at
https://git.sgu.ru/oldssu/ex-opensips/blob/cb9df8d59dbb254a9d862569fd5d11f6…
where
the check is as below?
if (sst_min_se > MIN(minse, se.interval)) {
Can someone confirm if this is broken, or my understanding is incorrect?
Regards,
Harneet
--
"Once you eliminate the impossible, whatever remains, no matter how
improbable, must be the truth" - Sir Arthur Conan Doyle
On Mon, May 07, 2018 at 04:44:14PM +0200, Daniel Tryba wrote:
> Sure. Attached. Problem appears to be that the topos query can't find
> callid-totag (from the response).
>
> I'll try the same scenario with the mysql backend to see if it behaves
> different.
Config works fine with mysql as topos backend. So the bug is restricted
to topos-redis.
Hello,
I am proxying all RTP through RTPEngine. Everything works fine until about
5 seconds into the call, when rtpengine enters kernelization, after which
all RTP forwarding ceases. I've checked the required iptables entries, and
all looks good.
Here is a description of my environment:
# cat os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
# kamailio -v
version: kamailio 5.6.2 (x86_64/linux) 54a9c1
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,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST,
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: 54a9c1
compiled on 16:02:49 Dec 1 2022 with gcc 10.2.1
# rtpengine -v
Version: 11.1.1.3-1~bpo11+1
Michel Pelletier
Hello ,
im using kamailio with two interfaces external and internal.
i need a way either to :
* enable topoh hiding only when outgoing interface is external ( mask contact and Via ip only when ougoing interface is external
* or if it is not possible to enable it only in one direction.i want to know how to configure dynamic(for example in xavp or avp) ip to put in Contact and Via when topoh is enabled.
i see that the 'mask_ip' parameter of topoh module is a string. so we can not set a dynamic value here unfortunately.
Thanks
Hello,
I'm continuing investigations on Kamailio and stress test. Got it again in
the state where it's not accepting any new TCP/TLS connections (UDP still
works though), but all looks good from lsof/netnstat part, like system is
not reporting any zombie connections. Restart of Kamailio process helps
This time I got output of kamctl trap
Put it here: https://pastebin.com/iYrNZ8U9
kamailio --version
version: kamailio 5.6.2 (x86_64/linux) 54a9c1
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,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST,
HAVE_RESOLV_RES
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: 54a9c1
compiled on 14:01:01 Oct 18 2022 with gcc 4.8.5
It's statically linked with tlsa pointing on openssl-1.1.1q
Settings related to TLS are:
fork=yes
children=4
tcp_children=12
enable_tls=yes
tcp_accept_no_cl=yes
tcp_max_connections=63536
tls_max_connections=63536
tcp_accept_aliases=no
tcp_async=yes
tcp_connect_timeout=10
tcp_conn_wq_max=63536
tcp_crlf_ping=yes
tcp_delayed_ack=yes
tcp_fd_cache=yes
tcp_keepalive=yes
tcp_keepcnt=3
tcp_keepidle=30
tcp_keepintvl=10
tcp_linger2=30
tcp_rd_buf_size=80000
tcp_send_timeout=10
tcp_wq_blk_size=2100
tcp_wq_max=10485760
open_files_limit=63536
Can you please help to read gdb output and understand where I missed in
config?
Thanks in advance!
--
Best regards,
Ihor (Igor)
Dear List,
We’re using Kamailio to load balance MRCP requests to multiple backend groups with a configuration as follows:
# kamailio.cfg
...
...
route[DISPATCH] {
if($ua=="mrcp_backend_1") {
if(!ds_select_dst("1", "4")) {
send_reply("404", "No destination");
exit;
}
}
if($ua=="mrcp_backend_2") {
if(!ds_select_dst("2", "4")) {
send_reply("404", "No destination");
exit;
}
}
xlog("L_DBG", "--- SCRIPT: going to <$ru> via <$du>\n");
t_on_failure("RTF_DISPATCH");
route(RELAY);
exit;
}
...
...
# dispatcher.list
1 sip:mrcp01.server.int:8060;transport=tcp
1 sip:mrcp02.server.int:8060;transport=tcp
2 sip:mrcp03.server.int:8060;transport=tcp
2 sip:mrcp04.server.int:8060;transport=tcp
With this configuration, Kamailio load balances the initial SIP INVITE among the MRCP servers. After the INVITE, the service communicates directly to the MRCP servers via SIP (for hanging up the call), MRCPv2 (for sending speech control messages), and RTP (for sending audio).
We would like to implement a configurable number of retries, so that if a particular backend times out, Kamailio would retry X times to other backend(s). In short, something equivalent to HAProxy’s retries, but for Kamailio. This probably implies having Kamailio always as part of our communication (not just load balancing the initial SIP INVITE).
I haven’t been able to find much information about this, could someone provide some pointers?
Thank you so much
With best wishes,
Unai Rodriguez
Hello All
I have below setup :
SBC -> kamailio -> Media server(remote) -> web-client
Call comes from sbc to kamilio and it relays to Remote server to end user,
In Ringing state if remote server goes down then in kamailio there is any
way to Recover that ringing call like we can generate new invite for other
Remote server which is active state, for relaying call i am using
dispatcher module..
I tried with tm.cancel RPC command but it works only if the remote server
is running , when I crash the remote server at that time tm.cancel is not
generating cancel to remote server.
Please suggest if there is any other way to generate INVITE.
Regards
Devang Dhandhalya
--
* <https://www.ecosmob.com/>
*
*Disclaimer*
In addition to generic
Disclaimer which you have agreed on our website, any views or opinions
presented in this email are solely those of the originator and do not
necessarily represent those of the Company or its sister concerns. Any
liability (in negligence, contract or otherwise) arising from any third
party taking any action, or refraining from taking any action on the basis
of any of the information contained in this email is hereby excluded.
*Confidentiality*
This communication (including any attachment/s) is
intended only for the use of the addressee(s) and contains information that
is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination,
distribution, or copying of this communication is prohibited. Please inform
originator if you have received it in error.
*Caution for viruses,
malware etc.*
This communication, including any attachments, may not be
free of viruses, trojans, similar or new contaminants/malware,
interceptions or interference, and may not be compatible with your systems.
You shall carry out virus/malware scanning on your own before opening any
attachment to this e-mail. The sender of this e-mail and Company including
its sister concerns shall not be liable for any damage that may incur to
you as a result of viruses, incompleteness of this message, a delay in
receipt of this message or any other computer problems.