Excellent.
Thanks again, Henning.
From: Henning Westerholt [mailto:h...@skalatan.de]
Sent: Sunday, September 22, 2019 3:58 AM
To: Kamailio (SER) - Users Mailing List ; Cody
Herzog
Subject: Re: [SR-Users] qm_find_free() Free fragment not found, called from
xcap_server, no more pkg
Hello Cody
From: Henning Westerholt [mailto:h...@skalatan.de]
Sent: Thursday, September 19, 2019 2:22 PM
To: Kamailio (SER) - Users Mailing List ; Cody
Herzog
Subject: Re: [SR-Users] qm_find_free() Free fragment not found, called from
xcap_server, no more pkg
Hello Cody,
you only need to enable the mem
oduce.
Thanks again.
From: Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Sent: Wednesday, September 18, 2019 11:32 PM
To: Kamailio (SER) - Users Mailing List ; Cody
Herzog
Subject: Re: [SR-Users] qm_find_free() Free fragment not found, called from
xcap_server, no more pkg
Hello,
first,
Hello.
Recently, for the first time, we experienced an apparent memory issue in our
production environment. Here's an example of the relevant log messages:
Sep 13 18:55:22 SIPCOMM /usr/local/sbin/kamailio[2302]: ERROR:
[core/mem/q_malloc.c:286]: qm_find_free(): qm_find_free(0x7fd8bbcfc010,
13
Another thought...
Perhaps 'async_task_route()' automatically creates a transaction, which is why
I was having problems with the calls to 't_newtran()' and 't_release()' after
the route had been changed to execute through 'async_task_route()'.
If so, then maybe it's safe for my async presence r
Thanks for the quick reply, Alex.
I will try to provide more context information.
The route in question is related to presence.
Our usage of t_newtran() is very similar to the following presence examples:
https://github.com/kamailio/kamailio/blob/master/test/unit/presence.cfg
https://lists.kama
Hello.
I have read that the primary use of 't_newtran()' is to handle SIP
retransmissions.
Given that, is there any reason to use it when operating over TCP/TLS?
I recently changed a route to operate asynchronously through
'async_task_route()'. When I did, calls to 't_newtran()' started failin
Thanks, Juha.
You are correct. That feature request is directly relevant to this thread.
I will upvote the feature request, and add a link back to this thread.
The proposed workaround of using async workers is the one I opted to use.
___
Kamailio (SER)
Thanks.
Regarding UDP, that all makes sense.
For my short-term needs, to minimize risk and infrastructure changes, it looks
like the ASYNC module will work.
Here's the basic outline of what I'm doing:
async_workers=8
route
{
route(CHECK_IS_EXPENSIVE_OPERATION);
>A common design which avoids this is to use TCP at the client edge and
>UDP inside the network core. This is one of the reasons why TCP is not
>optimal for use inside the core.
That makes sense, but is unfortunately not an option for me due to strict
security requirements.
I need to use TLS on t
Thanks very much for the quick replies, Alex and Brandon.
The main reason I'm hitting a bottleneck is because my architecture is not
optimal.
I have a number of edge proxies which communicate with all my clients.
The clients are usually distributed pretty evenly across all the proxies.
On those
Hello.
I'm curious as to how SIP messages received over TLS are divided amongst the
available TCP workers.
Based on some searching, I was hoping and expecting that the messages would be
load balanced amongst the TCP workers at the level of individual SIP messages.
However, with my configuratio
My pleasure. Thanks very much.
From: Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Sent: Tuesday, August 8, 2017 1:17 AM
To: Cody Herzog ; Kamailio (SER) - Users Mailing
List
Subject: Re: [SR-Users] Core crash in del_lump() "offset exceeds message size"
when using subst() insid
Yes. The crash was happening when using subst() or subst_body() inside of
event_route[tm:local-request].
From: Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Sent: Monday, August 7, 2017 12:55 PM
To: Cody Herzog ; Kamailio (SER) - Users Mailing
List
Subject: Re: [SR-Users] Core crash in
tantin Mierla [mailto:mico...@gmail.com]
Sent: Monday, August 7, 2017 12:15 AM
To: Cody Herzog ; Kamailio (SER) - Users Mailing
List
Subject: Re: [SR-Users] Core crash in del_lump() "offset exceeds message size"
when using subst() inside tm:local-request route.
Hello,
can you make a pull
tin Mierla [mailto:mico...@gmail.com]
Sent: Sunday, July 30, 2017 11:12 PM
To: Kamailio (SER) - Users Mailing List ; Cody
Herzog
Subject: Re: [SR-Users] Core crash in del_lump() "offset exceeds message size"
when using subst() inside tm:local-request route.
Hello,
what's the ve
Hello.
Inside the tm:local-request route, I am trying to modify the body of outgoing
NOTIFY messages using the subst_body() function.
Things seem to work fine most of the time. The NOTIFY messages are correctly
modified. However, I will very rarely hit a crash.
I can force the crash to happen
Thanks for the quick reply.
Pull request #1101 created:
https://github.com/kamailio/kamailio/pull/1101
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello.
I'm running Kamailio 4.3.5 on Ubuntu Server 14.04.
I just started using the app_python module together with the OpenTok Python
SDK, described here:
https://tokbox.com/developer/sdks/python/
My basic Python test script works fine, but when I add an import statement in
the Python script
19 matches
Mail list logo