Hi all,
I'm doing some experimenting with kamailio -- currently looking for a replacement of our existing (aging) SIP infrastructure.
One of the experiments that I'm doing is testing the dialog module's dlg_set_timeout function. The issue that I'm having is while I do see that kamailio is generating a BYE, and sends it out to the B-leg of the call properly, the BYE goes to a private address on the A-leg.
To Note:
- kamailio is behind a NAT (on AWS)
- both UA endpoints are remote and are both behind a NAT
- Not sure if this matters, but I do have the topos module enabled, though I see the same behavior regardless if it's enabled or not.
- Have set nathelpers (fix_nated_register, fix_nated_contact,etc...) which helps calls between endpoints and the endpoints themselves are able to send/receive BYEs when they generate them; however doesn't seem to help if kamailio locally generates the BYE.
The only thing I do see within my logs is when the BYE is being generated by kamailio, it uses the private IP of my UA and not public for the caller. Callee, the public address is referenced. If more information is needed, please let me know (just didn't want to spam my script/ logs). Thanks.
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: dialog [dlg_req_within.c:399]: send_bye(): sending BYE to caller
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:458]: t_uac_prepare(): next_hop=<sip:1000@10.0.0.47:38606;line=9k4wsgc9>
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:158]: dlg2hash(): hashid 40484
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:679]: parse_msg(): SIP Request:
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:680]: parse_msg(): method: <BYE>
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:682]: parse_msg(): uri: <sip:1000@10.0.0.47:38606;line=9k4wsgc9>
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:684]: parse_msg(): version: <SIP/2.0>
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Via] type 1
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_via.c:1300]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK42e9.4a962087000000000000000000000000.0>; state=16
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:557]: parse_headers(): this is the first via
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [To] type 3
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=ueisi99vbf
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=29
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): <To> [61]; uri=[sip:1000@fakedomain.com]
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body (44)[<sip:1000@fakedomain.com>], to tag (10)[ueisi99vbf]
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [From] type 4
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [CSeq] type 5
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <BYE>
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Call-ID] type 6
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Content-Length] type 12
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field(): content_length=0
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Max-Forwards] type 8
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of header
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=1132060721
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=29
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:1013]: tps_request_sent(): handling outgoing request (1, 1)
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:417]: tps_pack_message(): compacted headers - x_via1: [SIP/2.0/UDP <KAMAILIO PUBLIC IP>:5060;branch=z9hG4bK42e9.4a962087000000000000000000000000.0](85) - x_via2: [](0) - x_vbranch1: [z9hG4bK42e9.4a962087000000000000000000000000.0](46)
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:539]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [](0) - s_rr: [](0)
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:544]: tps_pack_message(): compacted headers - as_contact: [](0) - bs_contact: [](0)
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [tps_msg.c:1027]: tps_request_sent(): no x-uuid header - nothing to do
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/msg_translator.c:1799]: check_boundaries(): no multi-part body
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: topos [topos_mod.c:567]: tps_msg_sent(): new outbound buffer generated
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:686]: send_prepared_request_impl(): uac: 0x7f22f94448e8 branch: 0 to 10.0.0.47:38606
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: <core> [core/onsend.c:50]: run_onsend(): required parameters are not available - ignoring
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: dialog [dlg_req_within.c:432]: send_bye(): BYE sent to caller
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: dialog [dlg_req_within.c:399]: send_bye(): sending BYE to callee
Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:458]: t_uac_prepare(): next_hop=<sip:1001@<UA PUBLIC IP>:5066>Jan 26 16:33:29 localhost /opt/kamailio-5.6.2/sbin/kamailio[1238222]: DEBUG: tm [uac.c:158]: dlg2hash(): hashid 40482
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)
Hi
I'm trying to work around Route-Header and Via Issues with the two
topology hiding modules topoh and topos and trying to figure out, which
one works better for our environment.
My conclusion so far:
topos creates very clean header, but needs a database or redis. I'm
always reluctant in adding more components which could fail or cause
load.
topoh also works, but it worries me a bit that according to the manual:
https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask…
a private IP is used to mask the contact header.
I have come across a CPE which, as far as I see, is misbehaving by
ALWAYS sending a PRACK to the Hostname or IP found in the Contact
header, and ignoring Route and Via Header.
So why using a private IP as 'mask' and not the IP or Hostname of the
actual kamailio instance?
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
______________________________________________________
(removed sr-dev from CC)
Hello,
you can do that with the reply_route and/or onreply_route, for an example check out example cfg or this:
https://www.kamailio.org/docs/modules/devel/modules/tm.html#tm.f.t_on_reply
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com<https://gilawa.com/>
From: HimaBindu G <himabindu.garadareddy(a)gmail.com>
Sent: Tuesday, January 24, 2023 3:16 PM
To: sr-users(a)lists.kamailio.org; sr-dev(a)lists.kamailio.org
Subject: [sr-dev] Is there any Function or parameter to check Initial Invite Response on Kamailio
Hi All,
Can you please suggest any function or parameter to check Initial Invite Response from the backend.
Thanks & Regards,
Hima Bindu.
Hi All,
Hope you are all well?
I am hoping you can help with a bit of syntax I am struggling to get working in the intended way. (We are using Kamailio 5.5.3 and using Kemi/python.)
The scenario is in AWS where we have separate Kamailio and RTPengine instances, with a cluster of FreeSWITCH EC2's on private addresses only.
In the current setup, all RTP routes via the NAT gateway and back to the private IP of the selected FreeSWITCH (and vice versa). This works in the current config, but I would want this traffic not going via the NAT gateway and use the private address and route internally on the VPC. (These EC'2 have only 1 network interface and that cannot be changed for this work.)
So anything between FreeSWITCH and Kamailio/RTPengine uses the private IP's for media, the rest use public IP's.
It is good to note that the RTPengine's are the same in each set (3 total RTPengine's), just using the public/private IP's based on set ID.
My first aim is to use KSR.permissions.allow_source_address() to check if the source address is from the FreeSWITCH cluster and set the rtpengine setID based on this. I have used this method for different parts of the config and it works.
I am failing at this first step it seems, as no matter what I use in the function (below) it defaults and uses the public IP's in SDP. (No matter if I use the same setID in each set)
kamailio.cfg snippet:
# ----- rtpengine params -----
modparam("rtpengine", "setid_avp", "$avp()")
# Public IP's ID 1:
modparam("rtpengine", "rtpengine_sock", "1 == udp:5.5.5.5:2223 udp:6.6.6.6:2223 udp:7.7.7.7:2223")
# Internal IP's ID 2:
modparam("rtpengine", "rtpengine_sock", "2 == udp:10.0.0.1:2223 udp:10.0.0.2:2223 udp:10.0.0.3:2223")
Kemi file snippet:
# RTPengine Options for different SetID
def ksr_route_rtpengine(self, msg):
if KSR.textops.has_body_type("application/sdp") > 0 :
# Source address is private subnet - use RTPengine set 2 (private IP's)
if KSR.permissions.allow_source_address(400) == 1:
KSR.rtpengine.set_rtpengine_set(2)
KSR.rtpengine.rtpengine_manage(
"RTP/AVP replace-session-connection replace-origin port-latching ICE=remove")
else:
# Source address is NOT private - use RTPengine set 1 (public)
KSR.rtpengine.set_rtpengine_set(1)
KSR.rtpengine.rtpengine_manage(
"RTP/AVP replace-session-connection replace-origin port-latching ICE=remove")
KSR.xlog.xlog("L_INFO", "RTPengine handling Block")
return 1
Group 400 is the private subnet of the FreeSWITCH clusters we have behind on private addresses and the list contains the subnet of private IP's.
Using the above, the Kamailio starts fine and understands/loads each set of RTPengine's and calls work with audio. but regardless of the set number used (even only using set 2 in both) it defaults to public IP's in the SDP. (This is the only place in the config where this function is defined)
My SDP from FreeSWITCH egress to Kamailio/RTPengine has private IP's in the SDP.
The only thing I do not fully understand is the setid_avp - specifically $avp() block and if this needs to stay empty, or be duplicated with the set ID in each one.
Any help would be greatly appreciated in understanding where I am going wrong here.
Thanks,
John.
Hello,
While trunking with an Oracle SBC, I was lately required to include a
port number in INVITE To: field.
Would you qualify this as a "legal requirement" (according to SIP Standards) ?
Best regards
Hi
I am struggling with DMQ and dialog DB storage leading to orphan or
duplicate entries in database and not loading all dialog information
upon restart.
usrloc on the other side, also using local db storage and dmq, works
flawlessly even when restarting one node. All location information is
replicated between the databases via DMQ.
So trying to find what is different.
usrloc module:
modparam("usrloc", "db_url", DBLOCAL)
modparam("usrloc", "db_mode", 2)
modparam("dmq_usrloc", "enable", 1)
modparam("dmq_usrloc", "sync", 1)
dialog module:
modparam("dialog", "db_url", DBLOCAL )
modparam("dialog", "db_mode", 1 )
modparam("dialog", "db_skip_load", 0)
modparam("dialog", "enable_dmq", 1)
via kamcmd dlg.list I see that dialog information is being replicated
between the two nodes. But I can only find the dialog in the local
database of the node which is handling the call.
Is this the expected behavior?
I also just found how to create duplicate entries in the database...
* Run a call on Node A, verify the dialog information is store in the
local database and replicated to node B via DMQ.
* Restart Kamailio on Node A.
There I suspect, node A is restoring Dialog Information via DMQ from
Node B and loading the same information from database, leaving
duplicates in dialog_vars.
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,
I would like to announce that Call for Presentations at Kamailio World
2023 is now open. You can submit your proposal or see more details at:
- https://www.kamailioworld.com/k2023/call-for-speakers/
The 11th edition of the conference returns to Berlin, Germany, during
June 5-7, 2023, as an in-person event. Expect a large range of
participants, developers and community members as well as
representatives of other popular open source VoIP projects such as
Asterisk or FreeSwitch.
Looking forward to meeting many of you there!
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com
Hello,
I'm encountering performance issues with Kamailio (5.5.2).
I'm using a custom Kamailio module that loads routing data in memory, using Kamailio shared memory.
This routing data is very large. It can be fully reloaded through a Kamailio RPC command (which is done once each day).
When reloading, two sets of data are maintained, one "loading" and another "current" (the latter being used to handle SIP requests).
When loading of the new data is finished, it is swapped to "current". Then, memory of the old (now unused) data is freed.
I've noticed that when Kamailio is freeing the old data, there is a very significant performance impact on SIP requests.
This is surprising to me, because the SIP requests do not use this old data.
This is not a CPU issue, idle CPU% is at about 99% at that moment.
I'm using the following functions :
- shm_mallocxz
- shm_free
From what I understand, shm_free is actually "qm_shm_free" defined in "src\core\mem\q_malloc.c" (the default shared memory manager being "qm").
I've noticed that there is also a variant shm_free_unsafe ("qm_free"), which does not perform locking.
I'm wondering if the lock could be the cause of my performances issues ?
(But I'm not sure how this could be possible, because although the SIP requests need to access the shared memory allocated, they do not use directly the functions from the share memory manager.)
If the performances issues are causes by the lock, could I use the unsafe version "safely" ? (considering that it is guaranteed that the old data cannot be used by anyone else)
Thanks for your help.
Regards,
Nicolas.
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.