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,
is there an rsync endpoint available or is there a possiblity of setting
this up? Creating a mirror via HTTP is a rather quick and dirty solution
and while the deb-repo can be mirrored using debmirror, the rpm repo is
hard to sync to a non-CentOS-based machine due to missing dependencies
such as yum and reposync in latest Debian-based systems.
Would be great to get some input in regards to this topic.
Cheers
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.
Hi,
Intermittently we are observing the following error when checking if given
header is present in SIP INVITE:
SystemError: returned a result with an error set
The complete stack trace is (some names redacted):
11(28) ERROR: {1 195 INVITE nMHZDN.10nOIDt4ldOwz5cqz0XnMepA9} app_python3
[python_support.c:156]: python_handle_exception(): apy_exec:
modify_headers((null)): Unhandled exception in the Python code:
TypeError: an integer is required (got type NoneType)
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/etc/kamailio/kamailio.py", line 25, in modify_headers
self.modify_header("SomeHeader")
File "/etc/kamailio/kamailio.py", line 29, in modify_header
present = KSR.hdr.is_present(header_name)
SystemError: returned a result with an error set
Kamailio version (kamailio -v output):
version: kamailio 5.4.6 (x86_64/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,
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 8.3.0
Operation system: Linux kamailio-5c7484c74d-vhhr8 5.4.0-1056-azure
#58~18.04.1-Ubuntu SMP Wed Jul 28 23:14:18 UTC 2021 x86_64 GNU/Linux
Are you able to help me find the root cause of this issue?
Pozdrawiam / Best regards,
Wojtek
--
*For more information on how and why we collect your personal
information, please visit our Privacy Policy
<https://www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackI…>.*
Hello,
it is the time to plan a bit the road to the next major release, to be
versioned 5.6.0.
The 5.5.0 was release about one year ago, therefore it is time to set
the milestones for getting 5.6.0 out.
I would propose to freeze the development on Thursday, April 14, 2020,
test till mid of May or so, then release v5.6.0.
There is a lot of development to existing components and a couple of new
modules.
If anyone wants a different time line towards 5.6.0, let's discuss and
choose the one that suits most of the developers.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Hello,
please keep the list in CC, that others can comment as well.
Beside from the obvious (improving the performance of the lua API call), you could use indeed asynchronous processing. If you just use the lua code to emit the REST request, using a native http client module would be probably also faster as doing it over lua.
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com<https://gilawa.com/>
From: Giovanni Jose <gio.jose(a)gmail.com>
Sent: Wednesday, March 30, 2022 5:17 PM
To: Henning Westerholt <hw(a)gilawa.com>
Subject: Re: [SR-Users] More than TCP 800 concurrent calls, slows Kamailio (LUA FILE API REQUESTS)
Hello Henning, Thanks so much for the fast response
I just commented the loop and I was hitting the backend and it's slow anyway maybe it's because, for this type of implementation when the destination of the call is decided by the API backend, I need to use the http_async_client module? I am noticing that for high volume calls kamailio slows the traffic and shows errors because there's a delay that is been added when the backend responds for every call.
On Tue, Mar 29, 2022 at 11:53 PM Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> wrote:
Hello,
why are you sleeping for 1s in the loop? This will cause Kamailio to block processing. I also do not see any stop condition on the loop, so it will loop until the limit.
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com<https://gilawa.com/>
From: sr-users <sr-users-bounces(a)lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>> On Behalf Of Giovanni Jose
Sent: Tuesday, March 29, 2022 9:46 PM
To: sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
Subject: [SR-Users] More than TCP 800 concurrent calls, slows Kamailio (LUA FILE API REQUESTS)
Hello Guys I am having this issue where kamailio is receiving requests from SIPp (we are currently testing the platform and doing QA) but if we do more than 800 concurrent calls kamailio starts failing and slowing the requests, The scenario is the following:
I am sending 5000 calls at 100 CPS on TCP and I am having this route in the configuration file:
# Handle the calls to api
route[CALL_API] {
xlog("L_NOTICE"," Call request $var(call_request) method: $rm \n");
$var(loop_true)=1;
while ($var(loop_true)) {
if(!lua_run("call_request","$var(call_request)","$sht(token=>new_token)")) {
xlog("L_NOTICE", "SCRIPT: failed to execute lua function!\n");
}
if ($var(loop_true)){
sleep("1");
}
}
xlog("L_NOTICE", "SCRIPT: Sucess to execute lua function!\n");
}
So I am executing a LUA script for the requests and the API response will tell the destination of the call.
At 800 concurrent calls, I can notice SLOWLINESS in the SIPp testing tool, and then I will start receiving 408 timeouts.
This sounds like a load issue or something because I believe there's a time that it's been added every time we hit the backend and wait for the response.
any help will be appreciated
Regards
Gio
Hello,
I'm having some trouble with what I think is the dialog module.
I've got Kamailio 5.5.4 running well for some time. Recently I added
Asterisk to the mix and have come across an issue.
Call to Kamailio. Kamailio sends it to Asterisk. Asterisk may decide
to "forward" the call. To do this it will place a new outbound call
through Kamailio. From the user perspective, this works absolutely fine
(invite, ringing, ok, bye). The acc module handles it fine also.
However dialog does not, and the events for ok and bye do not fire on
the original call. They do fire for the forwarded call.
I've added some logging output to try to isolate the problem, but I'm no
further ahead. Here's what I have. Any suggestions?
** Call initiated **
INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE rs=100
ru=<null> tu=sip:destination@endpoint DLG_status=<null> dlg-h-id=3360
INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE rs=100
ru=<null> tu=sip:fwddest@0.0.0.1:5060 DLG_status=<null> dlg-h-id=12036
INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE rs=183
ru=<null> tu=sip:fwddest@0.0.0.1:5060 DLG_status=<null> dlg-h-id=12036
INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE rs=183
ru=<null> tu=sip:destination@endpoint DLG_status=<null> dlg-h-id=3360
INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE rs=200
ru=<null> tu=sip:fwddest@0.0.0.1:5060 DLG_status=<null> dlg-h-id=12036
CRITICAL: dialog [dlg_timer.c:200]: update_dlg_timer(): Trying to update
a bogus dlg tl=0x7fa0494006e8 tl->next=(nil) tl->prev=(nil)
ERROR: dialog [dlg_hash.c:1329]: update_dlg_timeout(): failed to update
dialog lifetime
CRITICAL: dialog [dlg_timer.c:200]: update_dlg_timer(): Trying to update
a bogus dlg tl=0x7fa0494006e8 tl->next=(nil) tl->prev=(nil)
ERROR: dialog [dlg_hash.c:1329]: update_dlg_timeout(): failed to update
dialog lifetime
ERROR: dialog [dlg_profile.c:1028]: dlg_set_timeout_by_profile(): Unable
to set timeout on 3306:12036
NOTICE: acc [acc.c:270]: acc_log_request(): ACC: transaction answered:
timestamp=1648611824;time_unix=1648611824.346;method=INVITE;from_tag=as292200a1;to_tag=as75834dc4;call_id=7cef233547dca0ac7882ce5249b3b54c;code=200;reason=OK
INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE rs=200
ru=<null> tu=sip:destination@endpoint DLG_status=<null> dlg-h-id=<null>
NOTICE: acc [acc.c:270]: acc_log_request(): ACC: transaction answered:
timestamp=1648611824;time_unix=1648611824.354;method=INVITE;from_tag=as730369e7;to_tag=as3b06b3e2;call_id=53bad4f0034b61a5745163d82daef402;code=200;reason=OK
INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE rs=200
ru=<null> tu=sip:destination@endpoint DLG_status=<null> dlg-h-id=<null>
WARNING: dialog [dlg_handlers.c:1328]: dlg_onroute(): unable to find
dialog for ACK with route param '161.02d' [353:3360] and call-id
'53bad4f0034b61a5745163d82daef402'
WARNING: dialog [dlg_handlers.c:1328]: dlg_onroute(): unable to find
dialog for ACK with route param '161.02d' [353:3360] and call-id
'53bad4f0034b61a5745163d82daef402'
** The call is answered and endpoints can talk to each other **
** Now the original caller hangs up **
WARNING: dialog [dlg_handlers.c:1328]: dlg_onroute(): unable to find
dialog for BYE with route param '161.02d' [353:3360] and call-id
'53bad4f0034b61a5745163d82daef402'
NOTICE: acc [acc.c:270]: acc_log_request(): ACC: transaction answered:
timestamp=1648611831;time_unix=1648611831.933;method=BYE;from_tag=as730369e7;to_tag=as3b06b3e2;call_id=53bad4f0034b61a5745163d82daef402;code=200;reason=OK
INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE rs=100
ru=<null> tu=sip:fwddest@0.0.0.1:5060 DLG_status=<null> dlg-h-id=12036
INFO: <script>: onreply_route[MANAGE_REPLY] branch [0] rm=INVITE rs=200
ru=<null> tu=sip:fwddest@0.0.0.1:5060 DLG_status=<null> dlg-h-id=12036
ERROR: <script>: got result for bye = Bye!; DLG_lifetime = 8
NOTICE: acc [acc.c:270]: acc_log_request(): ACC: transaction answered:
timestamp=1648611832;time_unix=1648611832.115;method=BYE;from_tag=as292200a1;to_tag=as75834dc4;call_id=7cef233547dca0ac7882ce5249b3b54c;code=200;reason=OK
ERROR: dialog [dlg_handlers.c:363]: dlg_terminated_confirmed(): failed
to get dialog from params!
** Everything ends cleanly on the other SIP endpoints **
What can I do from here to try to isolate this further?
Thanks,
--
Trevor Peirce
AcroVoice Solutions Inc
Hello community,
We made some modifications to Kamailio PCSCF sample cfg file, so when PCSCF receiving an tcp SUBSCRIBE message it add ;transport=tcp to the end of Contact URI. Below is what we added the route block right after if (is_method("INVITE|SUBSCRIBE")) logic
if (is_method("SUBSCRIBE") && proto=='tcp') {
$var(original_contact_header) = $ct;
$var(new_contact_header) = $(var(original_contact_header){re.subst,/(.*:.*)(>);/\1;transport=tcp>/g});
remove_hf("Contact");
append_hf("Contact: $var(new_contact_header)\r\n");
msg_apply_changes();
}
We did see the ;transport=tcp been added but we also seeing a bad line ;alias=[...] is added before the To: line
[cid:image001.png@01D84375.8D109B20]
Does anyone know what function might cause this ;alias been added before To: line?
BR,
Weiqi