sr-users March 2019

sr-users@lists.kamailio.org

78 participants
99 discussions

How fair is the rtpengine loadbalancing?

by Daniel Tryba

I have 3 rtp backends defined with equal weights (33 each). But when I look at the number of calls being handled the spreaded load is always 5:4:3 for the machines in the orderd listed: modparam("rtpengine", "rtpengine_sock", "udp:10.235.32.60:7723=33 udp:10.235.32.59:7723=33 udp:10.235.32.58:7723=33") Looking at select_rtpp_node_new I see nothing unfair happening (with my total lack of knowledge of how the node set is populated). Anybody else noticing this?

5 years

Auth for SUBSCRIBE and others

by Kevin Olbrich

Hi! I am implementing forwarding of SUBSCRIBE (BLF) to an Asterisk behind Kamailio. This works but Kamailio is not requesting for Auth. I then added SUBSCRIBE to: https://github.com/kamailio/kamailio/blob/master/etc/kamailio.cfg#L746 And it now challenges the client correctly. Why does this line only show REGISTER? Shouldn't it request a challenge for all messages? And why does it work with INVITES ootb? Thank you! Kind regards Kevin

5 years

Job Offering: Software Engineer & Dev-Ops for VoIP & IMS

by Carsten Bock

Hi everyone, due to our ongoing growth in the area of mobile network infrastructure, we are currently looking into expanding our team. We are especially looking for: - Software Engineer VoIP & IMS ( https://www.ng-voice.com/software-engineer-voip-ims) - Dev-Ops (VoIP & IMS) (https://www.ng-voice.com/dev-ops-voip-ims) About us ng-voice was founded by a team of leading open-source and VoIP pioneers and passionate coders to develop software for mobile network operators. Our virtualized, cloud native solutions allow entrepreneurial-thinking mobile network operators to become software-centric and offer voice services on any 4G, 5G, WiFi or any other data network – from regular mobile network operators to private networks in remote areas. We are growing the team both in Hamburg and Berlin and are looking for new colleagues to join us. Your responsibilities • Help us deploying and integrating our software solutions • Have fun testing, validating and optimizing our solutions • Enjoy building things and solving complex problems • Proactively identify ways to unlock operational efficiency • Take care of your teammates and have fun growing a company Our requirements We are more interested in your experience and knowledge than in formal degrees: • Strong interest in telephony • Experience with signalling standards (e.g. SIP, DIAMETER) • Fluent in English • Efficient at driving deadlines and keeping yourself and others on topic Our technology stack • Docker; experience with Docker Swarm and Kubernetes is beneficial • Kamailio, RTPEngine, FreeSwitch • Redis, MySQL and RabbitMQ • SIP, RTP, DIAMETER What we offer • Flexible working hours and great office locations (Berlin and Hamburg) • Entrepreneurial culture and flat hierarchies • High degree of autonomy and no dress code • Competitive salary Please send your application to jobs(a)ng-voice.com. Let us know how your profile fits our requirements. And please let us know the earliest date you could join us plus your salary expectations. We look forward to getting to know you! Thanks, Carsten -- Carsten Bock I Managing Director ng-voice GmbH Millerntorplatz 1 I 20359 Hamburg I Germany www.ng-voice.com Mobile +49 (0)179-20 21 244 I Direct +49 (0)40-52 47 593-40 I Fax +49 (0)40-52 47 593-99 Sitz der Gesellschaft: Hamburg Registergericht: Amtsgericht Hamburg, HRB 120189 Geschäftsführer: Carsten Bock, Dr. David Bachmann Ust-ID: DE279344284 Hier finden Sie unsere handelsrechtlichen Pflichtangaben: http://www.ng-voice.com/imprint/

5 years

How can one change acc table name in Kamailio.cfg

by Z

For some reason these two modparams are always ignored. The table name used is always acc which is default name. How can I change the table name? loadmodule "acc.so" modparam("acc", "db_table_acc", "*acc_$time(year)_$time(mon)*") modparam("acc", "db_table_missed_calls", "*acc_$time(year)_$time(mon)*") Accounting works as expected otherwise. Appreciate any help. Thanks.

5 years

Re: [SR-Users] Problem at Rx Interface - kamailio P-CSCF 5.1.6

by Valentin Christoph

Hi all, Remember this question from 23.1. It's solved now, thanks for help:-) All the best Christoph Von meinem Samsung Galaxy Smartphone gesendet. -------- Ursprüngliche Nachricht -------- Von: Valentin Christoph <Christoph.Valentin(a)kapsch.net> Datum: 23.01.19 15:06 (GMT+01:00) An: sr-users(a)lists.sip-router.org Cc: Scherney Theodor <Theodor.Scherney(a)kapsch.net>, Onic Roman <Roman.Onic(a)kapsch.net> Betreff: [SR-Users] Problem at Rx Interface - kamailio P-CSCF 5.1.6 Hi all, We are using kamailio 5.1.6, configured as P-CSCF, facing following problem. Please indicate, if you need further information – e.g. I could provide a tshark trace. If during call setup (by simulated UAs) at the terminating P-CSCF the simulated PCRF rejects the Diameter AAR message, then the kamailio P-CSCF runs into a questionable behaviour. By calling the Rx_AAR() function in configuration, the processing of the 200 OK is suspended (by the ims_qos module) and then resumed with the receipt of the AAA message. Now the ims_dialog module is called with the dlg_terminate(“all”, “reason”) function, but the 200 OK has not yet been sent. The ims_dialog sends CANCEL downstream and 488 upstream. However, the 200 OK is sent additionally. We would rather have expected the ims_dialog module should send BYE in both directions. When we respond the CANCEL with 481 Call/Transaction does not exist (which we MUST according to RFC 3261), then we would expect the ims_dialog module at least now to react with BYE in both directions. Could you help? What’s our misunderstanding? How could we proceed to get this issue fixed? Kind regards Christoph P.S.: This is a retransmission, because the original message did not pass moderator approval due to the attached tshark trace The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.

5 years, 1 month

IMS: ims_isc, ims_registrar_scscf: some additions for 3rd party registration

by Valentin Christoph

Dear all, Dear Daniel, We had implemented a few additions for third party registration, based on kamailio 5.1.0 IMS modules. * either service info OR original REGISTER request or original 200 OK can be added as body to the 3rd party Registration Request, if indicated by the HSS in the user data * change: S-CSCF does not check for TEL URI, before it sends P-Associated URI to AS (SIP URIs are also sent) We would like to provide a pull request within the next days or week to have the changes as basis for a change in release 5.3.x. Drawback: probably our solution would need to be slightly modified, because we removed the check for TEL URI, if the S-CSCF sends the P-Associated-URI header to the AS in the 3rd party register request (maybe introduce a module parameter?). Any comments? Would it be reviewed and maybe taken for 5.3? All the best Christoph ____ Christoph VALENTIN Software Developer | R&D Core / SIP Core P +43 50 811 3785 | M +43 664 628 3785 christoph.valentin(a)kapsch.net<mailto:christoph.valentin@kapsch.net> Kapsch CarrierCom AG | Lehrbachgasse 11 | 1120 Vienna | Austria Company Register at: Commercial Court Vienna FN 223804 z | Registered Office Vienna | www.kapsch.net<http://www.kapsch.net/> [Kapsch Logo]<https://www.kapsch.net/> The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.

5 years, 1 month

event_route tm:branch-failure and onreply_route shared variables

by Володимир Іванець

Hello! I have Kamailio setup with registrar configured to allow multiple registrations. *branch_route[MANAGE_BRANCH]* contains *t_on_reply("REPLY")* and *t_on_branch_failure("FAILURE")*. *event_route[tm:branch-failure:FAILURE]* is used to do some logic, store information in htable and in the end it calls *t_relay* function. This creates new branch. Replies for this branch go to* onreply_route[REPLY]*. The problem is that I can not find appropriate variable that would be available in both *event_route tm:branch-failure* and *onreply_route*. I need it to get saved data from htable. $T_reply_ruid is available in first one but not in second. $T_branch_idx obviously changes so it can not be used. Some registrations do not have *Received* value so source IP address and ports can not be used. *Address* value can be compared with *Contact* header from responce tacket but it is so long that it looks like it's not optimal way to do. What interesting is that $T_reply_ruid is accessible in original replies for branches that have not failed. Does anyone know what variable can be used in this case or how to make sure that $T_reply_ruid will be set? Thanks a lot!

5 years, 1 month

Pseudo-Variable {$au} is NULL

by Daniel Meyer-Wendt

Hi All, I am updating our Kamailio from 4.0.6 to the latest 5.2.2, we use kamailio as LB in front of two asterisk server. My problem is that during registration forward to the asterisk servers {$au} is NULL This is the code we have, which is the one you find in most documentations $uac_req(furi)="sip:" + $au + "@" + $var(rip); I logged some Pseudo-Variable to see their contents: {$au} NULL {$aU} NULL {$Au} username(a)domain.com {$fU} username {$oU} NULL {$ru} rU: {sip:domain.com;transport=UDP and ended up doing this which works $uac_req(furi)="sip:" + $fU + "@" + $var(rip); Any idea what could be wrong? Thanks, Daniel

5 years, 1 month

Kamailio books

by Kevin Olbrich

Hi! Are there any Kamailio books? I am still struggling with Kamailio on scenarios that need more then REGISTER-offloading (like Kamailio cluster with BLF, custom NOTIFY, DMQ, etc.). Online docs are very limited or use Kamailio as a single tenant PBX. What I need is a high available and high performance proxy in front of asterisk, capable of handling thousands of tenants (each with BLF working). I am perfectly fine with building a solution for several months but I am still unable to understand everything from the docs. Where do the PROs and service companies get their knowledge from? Kind regards Kevin

5 years, 1 month

Kamailio crashing and infinite-looping when trying to free memory

by Enrico Bandiera

Hi guys, recently we had some issues with kamailio in production, a proxy at the edge of the infrastructure was crashing seemingly randomly, it happened a couple of times in a timespan of 4-5 days until a point where we found it in an endless loop, unable to process SIP packets anymore and printing in loop messages like these: 50(60) CRITICAL: <core> [core/mem/q_malloc.c:512]: qm_free(): BUG: freeing already freed pointer (0x7ff40a359450), called from core: core/usr_avp.c: destroy_avp_list_unsafe(626), first free core: core/usr_avp.c: destroy_avp_list_unsafe(626) - ignoring 50(60) CRITICAL: <core> [core/mem/q_malloc.c:512]: qm_free(): BUG: freeing already freed pointer (0x7ff409c4fa58), called from core: core/usr_avp.c: destroy_avp_list_unsafe(626), first free core: core/usr_avp.c: destroy_avp_list_unsafe(626) - ignoring We managed to replicate the crash and the loop in a dev environment with a lot of difficulties. It seems not related to the peak load, but to the growing number of processed calls The kamailio version is: version: kamailio 5.2.2 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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 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 5.3.1 Every time this happened it was the timer pid that was crashing or looping, we managed to get 2 core dumps of the crash and 1 of the loop (got it after killing the timer with SIGQUIT). The timer process crashes after attempting to free memory that it's not correctly managed. In particular we saw that it happens inside destroy_avp_list_unsafe() called by the tm timer, when uri_avps_from points to an invalid memory address. We don't use dialog, uac, http_async_client, but we do use topos. In the crash dumps it seems that there's something wrong inside free_cell_helper(), when trying to clean the dead_cell something goes wrong while freeing uri_avps_from, here's the crash log: 61(76) CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 66 0(15) ALERT: <core> [main.c:740]: handle_sigs(): child process 65 exited by a signal 11 0(15) ALERT: <core> [main.c:743]: handle_sigs(): core was generated 0(15) INFO: <core> [main.c:766]: handle_sigs(): terminating due to SIGCHLD <childs getting the SIGTERM signal> 0(15) CRITICAL: <core> [core/mem/q_malloc.c:512]: qm_free(): BUG: freeing already freed pointer (0x7f4d60a2e168), called from htable: ht_api.c: ht_cell_free(217), first free core: core/usr_avp.c: destroy_avp_list_unsafe(626) - ignoring 0(15) INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized Before the crash we have no warnings on errors about shared memory allocation backtrace: (gdb) bt full #0 0x00000000006371d7 in destroy_avp_list_unsafe (list=0x7f34f7a411b0) at core/usr_avp.c:625 avp = 0x2 foo = 0x2 __func__ = "destroy_avp_list_unsafe" #1 0x00007f351c6909ab in free_cell_helper (dead_cell=0x7f34f7a41018, silent=0, fname=0x7f351c796a02 "timer.c", fline=689) at h_table.c:260 b = 0x0 i = 1 rpl = 0x0 tt = 0x0 foo = 0x11c68daf2 cbs = 0x0 cbs_tmp = 0x7f34f80c3790 __func__ = "free_cell_helper" #2 0x00007f351c7291e6 in wait_handler (ti=1984410416, wait_tl=0x7f34f7a410a0, data=0x7f34f7a41018) at timer.c:689 p_cell = 0x7f34f7a41018 ret = 1 unlinked = 0 rcount = 1 __func__ = "wait_handler" #3 0x00000000004d0f56 in timer_list_expire (t=1984410416, h=0x7f34f6be7850, slow_l=0x7f34f6bea368, slow_mark=2702) at core/timer.c:874 tl = 0x7f34f7a410a0 ret = 0 #4 0x00000000004d13bd in timer_handler () at core/timer.c:939 saved_ticks = 1984410416 run_slow_timer = 0 i = 654 __func__ = "timer_handler" #5 0x00000000004d1845 in timer_main () at core/timer.c:978 No locals. #6 0x0000000000425cc8 in main_loop () at main.c:1727 i = 8 pid = 0 si = 0x0 si_desc = "udp receiver child=7 sock=127.0.0.1:5060 \000\000\000\000q\000\000\000@6y\000\000\000\000\000\000\b\206|\210X\322:\032\301\255\000\000\000\000\000\000\000\000 \000\000\000\000\000\000\000\002\000\000\000\000\063\275{\000\000\000\000\000>", '\000' <repeats 15 times>, "\320\220\377\226\374\177\000\000\351\022a\000\000\000\000" nrprocs = 8 woneinit = 1 __func__ = "main_loop" #7 0x000000000042ca76 in main (argc=10, argv=0x7ffc96ff9398) at main.c:2696 cfg_stream = 0x25ca010 c = -1 r = 0 tmp = 0x7ffc96ffa4c9 "" tmp_len = -1761635728 port = 32764 proto = -1761635632 options = 0x76c598 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 1492539644 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 2 n_lst = 0x7f351f6f6718 p = 0xffffffff <error: Cannot access memory at address 0xffffffff> st = {st_dev = 2049, st_ino = 1282695, st_nlink = 2, st_mode = 16895, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 4096, st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1552931478, tv_nsec = 972761643}, st_mtim = {tv_sec = 1552931478, tv_nsec = 972761643}, st_ctim = {tv_sec = 1552931478, tv_nsec = 972761643}, __glibc_reserved = {0, 0, 0}} __func__ = "main" In the loop dump we have a different situation, there's a loop in the uri_avps_from structure as you can see from the next pointers: (gdb) p *dead_cell->uri_avps_from $3 = {id = 66, flags = 275, next = 0x7ff40a359450, d = {p = 0x7ff40a9ad540, l = 140686126667072, data = "@\325\232\n\364\177\000"}} (gdb) p *dead_cell->uri_avps_from.next $4 = {id = 66, flags = 275, next = 0x7ff409c4fa58, d = {p = 0x7ff40a359480, l = 140686120031360, data = "\200\224\065\n\364\177\000"}} (gdb) p *dead_cell->uri_avps_from.next.next $5 = {id = 66, flags = 275, next = 0x7ff40a359450, d = {p = 0x7ff409c4fa88, l = 140686112651912, data = "\210\372\304\t\364\177\000"}} backtrace: (gdb) bt full #0 0x00007ff43152e67e in _IO_default_xsputn () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x00007ff43150150b in vfprintf () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00007ff431502ef1 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #3 0x00007ff43150032d in vfprintf () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #4 0x00007ff4315087f7 in fprintf () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #5 0x0000000000686e43 in qm_free (qmp=0x7ff409336000, p=0x7ff409c4fa58, file=0x7e0a75 "core: core/usr_avp.c", func=0x7e2d70 <__func__.8439> "destroy_avp_list_unsafe", line=626, mname=0x7e0a70 "core") at core/mem/q_malloc.c:512 __llevel = -3 qm = 0x7ff409336000 f = 0x7ff409c4fa20 size = 72 next = 0x0 prev = 0x0 __func__ = "qm_free" #6 0x0000000000637209 in destroy_avp_list_unsafe (list=0x7ff409e1b6c8) at core/usr_avp.c:626 avp = 0x7ff40a359450 foo = 0x7ff409c4fa58 __func__ = "destroy_avp_list_unsafe" #7 0x00007ff42ee5d9ab in free_cell_helper (dead_cell=0x7ff409e1b530, silent=0, fname=0x7ff42ef63a02 "timer.c", fline=689) at h_table.c:260 b = 0x0 i = 1 rpl = 0x0 tt = 0x0 foo = 0x12ee5aaf2 cbs = 0x0 cbs_tmp = 0x7ff409c5d420 __func__ = "free_cell_helper" #8 0x00007ff42eef61e6 in wait_handler (ti=89094309, wait_tl=0x7ff409e1b5b8, data=0x7ff409e1b530) at timer.c:689 p_cell = 0x7ff409e1b530 ret = 1 unlinked = 0 rcount = 1 __func__ = "wait_handler" #9 0x00000000004d0f56 in timer_list_expire (t=89094309, h=0x7ff4093b4850, slow_l=0x7ff4093b8058, slow_mark=5981) at core/timer.c:874 tl = 0x7ff409e1b5b8 ret = 0 #10 0x00000000004d13bd in timer_handler () at core/timer.c:939 saved_ticks = 89094309 run_slow_timer = 0 i = 861 __func__ = "timer_handler" #11 0x00000000004d1845 in timer_main () at core/timer.c:978 No locals. #12 0x0000000000425cc8 in main_loop () at main.c:1727 i = 8 pid = 0 si = 0x0 si_desc = "udp receiver child=7 sock=127.0.0.1:5060 \000\000\000\000q\000\000\000@6y\000\000\000\000\000\000\032 t\220\260\242\024\032\301\255\000\000\000\000\000\000\000\000 \000\000\000\000\000\000\000\002\000\000\000\000\063\275{\000\000\000\000\000>", '\000' <repeats 15 times>, "\220\306\336\071\377\177\000\000\351\022a\000\000\000\000" nrprocs = 8 woneinit = 1 __func__ = "main_loop" #13 0x000000000042ca76 in main (argc=10, argv=0x7fff39dec958) at main.c:2696 cfg_stream = 0x2292010 c = -1 r = 0 tmp = 0x7fff39dee4c9 "" tmp_len = 970901552 port = 32767 proto = 970901648 options = 0x76c598 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 2710999419 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 2 n_lst = 0x7ff431ec3718 p = 0xffffffff <error: Cannot access memory at address 0xffffffff> st = {st_dev = 2049, st_ino = 1282695, st_nlink = 2, st_mode = 16895, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 4096, st_blksize = 4096, st_blocks = 8, st_atim = {tv_sec = 1552931523, tv_nsec = 918435869}, st_mtim = {tv_sec = 1552994274, tv_nsec = 814438687}, st_ctim = {tv_sec = 1552994274, tv_nsec = 814438687}, __glibc_reserved = {0, 0, 0}} __func__ = "main" We are not sure on how to keep debugging this issue which is causing some serious troubles in our environment, any help is appreciated Here you can find the dumps (beware, 12M download but 1.5G once uncompressed): https://drive.google.com/file/d/1U0LZedyona8jJZHq6HaoqXpfnU83p6Sp/view?usp=… Due thanks to Giacomo Vacca who helped us to dig into this issue. Thanks

5 years, 1 month

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users March 2019