Hi all
On calls with privacy enabled to customers, I want to ensure no
information is disclosed. Not even if one would capture packets.
A PRACK and the 200 OK to a PRACK therefore may need the To and From
Header changed.
Unfortunately I seem not to be able to catch the 200 OK REPLY sent to a
PRACK with t_on_reply. It looks like they somehow pass completely
unprocessed through Kamailio (not completely Via Header are removed
accordingly)
Am I missing something?
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
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
______________________________________________________
Dear List,
I’m new to Kamailio and would like to set it up as a standalone general purpose SBC.
I’m having a hard time finding a guide specific for this. What can you recommend?
Thank you so much
With best wishes,
Unai Rodriguez
Hi,
Some exceptions generated in Python script cause a harmless traceback in the logs, while others cause Kamailio to crash:
Sep 22 06:28:34 proxy /usr/sbin/kamailio[3984]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 11
Sep 22 06:28:34 proxy /usr/sbin/kamailio[3957]: ALERT: <core> [main.c:783]: handle_sigs(): child process 3965 exited by a signal 11
Sep 22 06:28:34 proxy /usr/sbin/kamailio[3957]: ALERT: <core> [main.c:786]: handle_sigs(): core was generated
(gdb) where
#0 0x00007fdaea729079 in vfprintf () from /lib64/libc.so.6
#1 0x00007fdaea754179 in vsnprintf () from /lib64/libc.so.6
#2 0x00007fdac45e9afd in make_message () from /usr/lib64/kamailio/modules/app_python3.so
#3 0x00007fdac45e5bc9 in python_handle_exception ()
from /usr/lib64/kamailio/modules/app_python3.so
#4 0x00007fdac45ebfde in apy_exec () from /usr/lib64/kamailio/modules/app_python3.so
#5 0x00007fdac45ecef1 in python_exec2 () from /usr/lib64/kamailio/modules/app_python3.so
#6 0x0000000000474ee0 in do_action ()
#7 0x000000000048217d in run_actions ()
#8 0x0000000000474d39 in do_action ()
#9 0x000000000048217d in run_actions ()
#10 0x0000000000474d39 in do_action ()
#11 0x000000000048217d in run_actions ()
#12 0x0000000000474d87 in do_action ()
#13 0x000000000048217d in run_actions ()
#14 0x00000000004828c1 in run_top_route ()
#15 0x00000000005e8044 in receive_msg ()
#16 0x00000000004df772 in udp_rcv_loop ()
#17 0x0000000000429f5b in main_loop ()
#18 0x000000000043423e in main ()
Is there a reasonable way to try to prevent this type of mid-air explosion?
— Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Hi,
I'm looking at a kamailio config where all substdef have the syntax
"!regexp!subst!flags", "!DB_URL!db.example.com!g" but i can't find this
syntax in the documentation. It's currently running on a fairly modern 5.x
version and as far as i know it has never been on 4.x or older.
Does anyone know where this syntax is from and if it's possible/recommended
to simply replace it with "/regexp/subst"?
*Fredrik* *Dahlgren* | Senior SIP/VoIP Engineer
fredrik.dahlgren(a)freespee.com | LinkedIn
<https://www.linkedin.com/company/freespee/> | Twitter
<https://twitter.com/freespee>
Hello,
Kamailio SIP Server v5.5.5 stable release is out.
This is a maintenance release of the stable branch 5.5 that
includes fixes since the release of v5.5.4. There is no change to
database schema or configuration language structure that you have to do
on previous installations of v5.5.x. Deployments running previous v5.5.x
versions are strongly recommended to be upgraded to v5.5.5.
Note that 5.5 is the second last stable branch, still officially maintained
by Kamailio development team. The latest stable branch is 5.6, with
v5.6.1 being release out of it.
For more details about version 5.5.5 (including links and guidelines to
download the tarball or from GIT repository), visit:
* https://www.kamailio.org/w/2022/09/kamailio-v5-5-5-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Many thanks to all contributing and using Kamailio!
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online
Oct 10-13, 2022 (Europe Timezone)
* https://www.asipto.com/sw/kamailio-advanced-training-online/
Hi,
Instructions for upgrading from 5.5 to 5.6 don't include instructions for
the MySQL database schema changes:
http://www.kamailio.org/wiki/install/upgrade/5.5.x-to-5.6.0
Where can I get this information? It was always published in the past.
Best regards,
Leonid Fainshtein
Hello,
I am considering to release Kamailio v5.5.5 soon, likely on Monday or
Tuesday next week (Sep 19 or 20, 2022). This is the usual heads up
notification to see if anyone is aware of issues not yet reported to bug
tracker and if yes, do it as soon as possible to give them a chance to
be fixed.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online
Oct 10-13, 2022 (Europe Timezone)
* https://www.asipto.com/sw/kamailio-advanced-training-online/
Hello,
We’ve been running Kamailio 5.5.0 for a while now and recently ran into an issue where the application buffer would get full and Kamailio has a lot of difficulty keeping up with REG requests. This severely impacted Kamailio’s ability to perform and resulted in many REG timeouts.
Running ‘watch netstat -ulpn’ revealed the buffer issue.
We usually run the production system at log level INFO (2) and had not ran into any issues in the past.
When the buffer issue occurred and after some testing, we discovered that changing the log level to NOTICE (1) was sufficient to bring the system back into operational status.
For example, at log level INFO (2) we seem to achieve ~150-200 REG/s while at log level NOTICE (1) we reach ~500-700 REG/s.
I did find this article in the wiki and tried using the “-“ in front of the log path but this didn’t seem to help.
http://www.kamailio.org/wiki/tutorials/3.2.x/syslog
Even writing the logs directly to our external log server and preventing them from being written to the local disk doesn’t seem to alleviate the issue when the log level is set to INFO (2).
Does anyone have any experience with this or have any suggestions? We are finding it difficult to scale as a result of this issue.
Thank you in advance.
Amit
