I have a situation where I am seeing intermittently Kamailio having delays when relaying the BYE received from an external party
This is only affecting the BYE
We have 6 Kamailios stood up
3 linked to the SIP Providers (SBC)
3 for Registration (REG)
Language KEMI | Python
version: kamailio 5.5.1 (x86_64/linux) 278772-dirty
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: 278772 -dirty
compiled with gcc 9.3.0
Simplified Flow
PSTN >>>> Kamailio SBC >>>> FREESWITCH >>>> Kamailio REG >>>> SIP DEVICE
SIP DEVICE >>>> Kamailio REG >>>> FREESWITCH >>>> Kamailio SBC >>>> PSTN
This happens on all of them intermittently when receiving the BYE from either a SIP trunk or a SIP Device Publicly, it can take upto 1s to pass this onto the next hope (Freeswitch) on the local network. All BYEs passed between the local network relay in fractions of a second. All BYEs passed out of the KAMAILIO SBC or KAMAILIO REG to their respective public enpoints relay in fractions of a second but BYEs received from public on advertised address take upto 1s for Kamailio to process and relay.
i.e
PSTN >>> BYE >>>> KAMAILIO SBC (kamailio will sometimes take upto 1 second to relay this on to other kit on the internal solution. Freeswitch etc)
SIP DEVICE >>> BYE >>>> KAMAILIO REG (kamailio will sometimes take upto 1 second to relay this on to other kit on the internal solution. Freeswitch etc)
I am basing these timings on SNgrep and PCAP traces from homer.
Does anyone have any hints and tips on how I can debug this issue. I have enabled debug logging and replicated the issue but it doesn't show anything from what I can see as to why there is delays.
Thanks in advance
lewis
Hello,
I'm trying to get the dispatcher status from kamailio through the UDP
datagram but for some reason, it is getting just part of the output. Is
there any buffer that I have to increase to get the complete output?
command used:
```
echo '{"jsonrpc": "2.0", "method": "dispatcher.list", "reply_name":
"kamailio_reply_fifo", "id": 1}' | nc -u 192.168.1.1 8090
```
kamailio related config:
modparam("jsonrpcs", "fifo_name", "/tmp/kamailio_request.fifo")
modparam("jsonrpcs", "transport", 6)
modparam("jsonrpcs", "fifo_mode", 0600)
modparam("jsonrpcs", "fifo_user", "kamailio")
modparam("jsonrpcs", "dgram_socket", "udp:MY_INTERNAL_IP_ADDR:8090")
modparam("jsonrpcs", "dgram_timeout", 2000)
modparam("jsonrpcs", "pretty_format", 1)
output:
[image: image.png]
Thanks
Hi,
I'm using Kamailio 5.3 and I am interested in doing call forwarding. I am
interested in having a user "alice" bypass the SIP REGISTER step and have
their SIP INVITE request/call forwarded to another SIP user "bob" (who,
let's just say for now is within the same domain, so accessible by the same
SCSCF and if it makes things simpler, let's say that bob went through the
register step).
In the PCSCF configuration, I've tried doing something like this:
route {
route(TEST)
...
}
route[TEST] {
$ru = "sip:bob@domain.com"
if (!t_relay("scscf.domain.com",6060)) {
sl_reply_error();
}
exit;
}
Instead of $ru, I've also tried using uac_replace_to, providing both the To
and URI fields with Bob's SIP URI.
When I try using the $ru, the S-CSCF still seems to use Alice's R-URI
instead of Bob's.
When I try using uac_replace_to, I get a 403 error saying that I need to
register with the S-CSCF first.
Am I going about this the correct way? Thank you.
Derek
Hi everyone,
I'm trying to build tlsa module on redhat 7.9 server.
But I'm encountering the following compile errors.
Any ideas on how I can deal with this?
CC (gcc) [M tlsa.so] tls_util.o
CC (gcc) [M tlsa.so] tls_domain.o
CC (gcc) [M tlsa.so] tls_locking.o
CC (gcc) [M tlsa.so] tls_rand.o
CC (gcc) [M tlsa.so] tls_map.o
CC (gcc) [M tlsa.so] tls_cfg.o
CC (gcc) [M tlsa.so] tls_select.o
CC (gcc) [M tlsa.so] tls_dump_vf.o
CC (gcc) [M tlsa.so] tls_init.o
CC (gcc) [M tlsa.so] tls_bio.o
CC (gcc) [M tlsa.so] tls_config.o
CC (gcc) [M tlsa.so] tls_server.o
CC (gcc) [M tlsa.so] tls_rpc.o
CC (gcc) [M tlsa.so] tls_ct_wrq.o
CC (gcc) [M tlsa.so] tlsa_mod.o
CC (gcc) [M tlsa.so] tls_verify.o
LD (gcc) [M tlsa.so] tlsa.so
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libz.a(deflate.o):
relocation R_X86_64_32S against hidden symbol `_length_code' can not be
used when making a shared object
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libz.a(inflate.o):
relocation R_X86_64_32S against hidden symbol `zcfree' can not be used when
making a shared object
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libz.a(inftrees.o):
relocation R_X86_64_32 against `.rodata' can not be used when making a
shared object; recompile with -fPIC
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libz.a(trees.o):
relocation R_X86_64_32S against hidden symbol `_length_code' can not be
used when making a shared object
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libz.a(zutil.o):
relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making
a shared object; recompile with -fPIC
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libz.a(crc32.o):
relocation R_X86_64_32 against `.rodata' can not be used when making a
shared object; recompile with -fPIC
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libz.a(inffast.o):
relocation R_X86_64_32S against `.rodata.str1.1' can not be used when
making a shared object; recompile with -fPIC
/usr/bin/ld: tlsa.so: version node not found for symbol
SSLeay_version(a)OPENSSL_1.0.1
/usr/bin/ld: failed to set dynamic section sizes: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [tlsa.so] Error 1
make[1]: *** [modules] Error 1
Hello,
I'm receiving calls which I forward to a server I KNOW will reply with a
302. When I get that 302, I parse some information and then t_reply(302)
the originator. The 302 I create needs to have it's own contact header
which I am adding with append_to_reply(). That works great. BUT the contact
header from the original 302 is hanging around. Now I have two contact
headers :(
How can I get rid of the original 302's contact header? remove_hf() doesn't
work in this context since it's a reply. So I need a kind of
"remove_header_from_reply()".
Thanks,
Brett
Hello Kamailio Team!
I've tried following the documentation for http_async_query() with
suspend=1 and not getting results I'm expecting. Perhaps I'm
misunderstanding the documentation.
Basically I'm performing a http_async_query() with suspend set to 1 and a
"route_name" set to HTTP_REPLY.
When my query executes, it appears that Kamailio stops processing in that
route block, suspends, and then when a reply is available, it continues in
HTTP_REPLY. That makes sense. I pull the return value and set some $var and
$avp. When I get to the end of the HTTP_REPLY block, I'm EXPECTING it to
RESUME FROM the suspended location from the original route block, which it
does NOT seem to do. Is that expected?
For what it's worth, I did test just continuing my route logic in
HTTP_REPLY and just forgetting about the original route block (moved all
the remaining processing logic into HTTP_REPLY) However, existing $avp and
$vars that were already set within the transaction were not set. So that's
not possible either.
I'm pretty sure there is a right way to do this without getting hacky. Can
someone help me out?
And yes, I know what I'm trying to do sounds like sync, but I want async to
handle high volume and the potential for my external URL to lightly block.
I believe the right way to do this is with async+suspending.
Thank you,
Brett
Hello all,
Lately I faced an issue that Kamailio is not responding to some invite packets coming from SBC. When investigating I found that these packets exceeds MTU size.
Could this be the issue? Knowing that in Kamailio configuration I have a condition on is_method("INVITE"). Could be that in case of packet exceeding MTU size it's not considered as invite packet by Kamailio?
I have Kamailio 5.2.5.
Regards,
Ali Taher
Hi List
# ----- registrar params -----
modparam("registrar", "method_filtering", 1)
# modparam("registrar", "append_branches", 0)
modparam("registrar", "max_contacts", 10)
modparam("registrar", "max_expires", 3600)
modparam("registrar", "gruu_enabled", 0)
modparam("registrar", "retry_after", 30)
modparam("registrar", "xavp_cfg", "reg")
== snipp ==
# Handle SIP registrations
route[REGISTRAR] {
# We are authenticated.
# Create an AOR based on the auth_username for the location service.
$var(saveuri) = "sip:" + $aU + "@" + $rd;
# Set max_contacts limit via registration module reg xavp.
if ($avp(debug) > 0) {
xlog("L_INFO", "$cfg(route): Setting max_contacts to $avp(max_contacts) for $var(saveuri)\n");
}
$xavp(reg=>max_contacts) = $avp(max_contacts);
# Save Location!
$var(result) = save("location","0x00","$var(saveuri)");
if ($var(result) == -2) {
xlog("L_ERR", "$cfg(route): Too many contacts for $var(saveuri)\n");
sl_reply_error();
}
if ($var(result) == -1) {
xlog("L_ERR", "$cfg(route): Error saving location $var(saveuri)\n");
sl_reply_error();
}
if ($var(result) == 1) {
xlog("L_INFO", "$cfg(route): Contact $var(saveuri) inserted\n");
}
if ($var(result) == 2) {
xlog("L_INFO", "$cfg(route): Contact $var(saveuri) updated\n");
}
if ($var(result) == 3) {
xlog("L_INFO", "$cfg(route): Contact $var(saveuri) deleted\n");
}
if ($var(result) == 4) {
xlog("L_INFO", "$cfg(route): Contact $var(saveuri) returend\n");
}
exit;
}
== snapp ==
$avp(max_contacts) is set to 1
Still, multiple registrations are possible for the $aU in question.
What am I doing wrong?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Hello,
Please keep the list in CC.
Regarding opening new TLS 1.3 connection, this should work, but did not tested it right now. If not, open an issue on our tracker.
Regarding the option to restrict to only TSLv1.3 connection - I have added support for configuring this to git master version in commit 105600b3.
Maybe you can give it a try, the patch should probably apply to 5.6.x branch.
Cheers,
Henning
From: Helio <hok.sh10(a)gmail.com>
Sent: Wednesday, August 17, 2022 2:52 PM
To: Henning Westerholt <hw(a)gilawa.com>
Subject: Re: [SR-Users] TLSv1.3 support
Regarding the full support, I would like to know if Kamailio can start a TLSv1.3 connection as a client. Another point is if we can restrict to accept only TLS v1.3 and not TLSv1.2 for instance.
Thanks,
Helio
Em ter., 16 de ago. de 2022 às 11:45, Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> escreveu:
Hello,
not sure about the question about “full support”, maybe you can add details.
Kamailio supports connection with TLSv1.3:
$ openssl s_client -connect kam04.tst.domain.net:5061<http://kam04.tst.domain.net:5061> -tls1_3 2>&1 | tail -n 10
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
Cheers,
Henning
From: sr-users <sr-users-bounces(a)lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>> On Behalf Of Helio
Sent: Monday, August 15, 2022 8:01 PM
To: sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
Subject: [SR-Users] TLSv1.3 support
Hello,
I noticed that Kamailio has option TLSv1.2+. Does the Kamailio support full TLSv1.3? Or does it have any restrictions?
BR,
