May 2018 - sr-users - kamailio.org

RTPengine: shouldn't SDP <sess-version> be incremented when SDP is updated in-dialog?
by George Diamantopoulos 20 Nov '18

20 Nov '18

Hello all, I have the following issue (I think) with RTP engine. An INVITE comes in, and rtpengine will rewrite the SDP accordingly, as configured in kamailio.cfg. After some time a reINVITE is sent out in the opposite direction, for session refresh purposes. As I use rtcp-mux-offer in kamailio.cfg for this direction, RTPengine will inject the rtcp-mux parameter, and this reINVITE is forwarded to the UAC that sent the original INVITE. However, the SDP in the reINVITE is exactly the same as the SDP in the 200 OK to the original INVITE, with the exception of the rtcp-mux parameter. Since the SDP offered from the same end has changed, shouldn't session version be incremented as well? Does this sound like something that should be reported as a bug to rtpengine? Or am I missing something here? Thanks! Best regards, George Diamantopoulos

3 4

kamailio + rtpproxy behind NAT
by Bonjour Madame 05 Oct '18

05 Oct '18

Hello, I have kamailio and rtpproxy running on the same server located behind a router with NAT just like below. UA(internet)---public ip---router(NAT)--Kamailio+RTPproxy(private ip)--UA(private network) There are several issues like one way audio. I need users on the internet to communicate with each other, users on the private network to communicate with each other, and users on the internet and the private network to communicate with each other. What is the best approach? Best regards, Clarence

3 5

tcp Free fragment not found
by Diego Nadares 04 Oct '18

04 Oct '18

Hi guys! We have four a scripts that sends dlg.list command to kamailio through xmlrpc. They are not executed simultaneously. Sometimes, we are getting the following errors: fm_search_defrag(): fm_search_defrag(0x7f212c25a000, 5273984); Free fragment not found!2017-05-26T13:54:20.438736-03:00 drwsip02 /usr/local/sbin/kamailio[19833]: ERROR: <core> [mem/f_malloc.c:498]: fm_malloc(): fm_malloc(0x7f212c25a000, 5273984) called from core: tcp_main.c: tcpconn_new(957), module: core; Free fragment not found!2017-05-26T13:54:20.439101-03:00 drwsip02 /usr/local/sbin/kamailio[19833]: ERROR: <core> [tcp_main.c:959]: tcpconn_new(): mem. allocation failure2017-05-26T13:54:20.439344-03:00 drwsip02 /usr/local/sbin/kamailio[19833]: ERROR: <core> [tcp_main.c:3985]: handle_new_connect(): tcpconn_new failed, closing socket I all ready increased this two variables: tcp_conn_wq_max=30000000 tcp_rd_buf_size=5273226 How can I see how much memory xmlrpc is using? Any advice will be appreciated. Thanks in advance! Diego

2 2

Kamctl Stats Update
by Noah Mehl 07 Aug '18

07 Aug '18

Hey all, I was wondering if the kamctl stats output could be updated to provide a bit more parseable JSON? For instance: # kamctl stats shmem | jq . { "jsonrpc": "2.0", "result": [ "shmem:fragments = 18", "shmem:free_size = 467187808", "shmem:max_used_size = 69694104", "shmem:real_used_size = 69683104", "shmem:total_size = 536870912", "shmem:used_size = 41048984" ], "id": 4300 } I would hope would be more like this: { "jsonrpc":"2.0", "result":[ { "shmem":[ { "fragments":18, "free_size":467187808, "max_used_size":69694104, "real_used_size":69683104, "total_size":536870912, "used_size":41048984 } ] } ], "id":4300 } I apologize in advanced because I don’t have the skillset to contribute such a feature. Thanks! ~Noah

5 8

No cdr after Kamailio 5.0.4 and 5.2 dev restart
by Kordován Szabolcs 27 Jul '18

27 Jul '18

Hi All, In March there was a discus about this issue. We tested the new 5.2 dev and 5.0.4 version of Kamailio and we experience that If we restart Kamailio during the call the cdr won't be stored in table acc_cdrs but the data will be inserted to table acc and data will be deleted from table dialog and dialog_vars. Did I omit the fix for it? Thanks for your help. Best regards, Szabolcs

2 3

rtpengine installation dependencies
by Aqs Younas 05 Jul '18

05 Jul '18

Greetings list. This might not be related to Kamailio but I thought someone would be able to give a hand in resolving dependency during the installation of rtpengine on Debian 8 Jessie. It is complaining about below dependencies. root@debian-769mb-miami-01:/usr/src/rtpengine# dpkg-buildpackage dpkg-buildpackage: source package ngcp-rtpengine dpkg-buildpackage: source version 6.3.0.0+0~mr6.3.0.0 dpkg-buildpackage: source distribution unstable dpkg-buildpackage: source changed by Sipwise Jenkins Builder < jenkins(a)sipwise.com> dpkg-buildpackage: host architecture amd64 dpkg-source --before-build rtpengine dpkg-source: info: using options from rtpengine/debian/source/options: --extend-diff-ignore=.gitreview dpkg-checkbuilddeps: *Unmet build dependencies: debhelper (>= 10~) libbcg729-dev* dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) I tried to install debhelper from deb but complained from dh-autoreconf and that itself complained abount debhelpler. So, no one is being installed. Also, If someone can help me how to resolve dependency for libbcg729-dev too. Any pointer or hint or link to some installation guide would be more than welcome. Br, Aqs.

9 17

Kamailio 5.1.2 and Module PDB: pdb_query returns always 0
by Stefan Rüetschli 20 Jun '18

20 Jun '18

Hi I have here Kamailio 5.1.2 with PDB Module. I use the documented function from PDB-Module as follows: pdb_query("$rU", "$avp(i:82)"); xlog("L_INFO","PDB result $rU: $avp(i:82)\n"); The problem is, that $avp(i:82) is always 0. If I test the PDB-Server, with "pdbt -r localhost:5574 query <phonenumber>" I get a valid response. I use this already with Kamailio 4.3.6 and there it is working. https://kamailio.org/docs/modules/5.1.x/modules/pdb.html Any ideas? Thanks & regards Stefan

2 8

Memory leak in tm with push notifications
by Ivaylo Markov 14 Jun '18

14 Jun '18

Hello, I am trying to set up Kamailio as a push notifications proxy, closely following the example in the "Kamailio in a Mobile World" presentation (https://www.slideshare.net/FedericoCabiddu/kamailioinamobileworld-51617342) I am running Debian 9 and Kamailio 5.1.3 from the official Debian repositories. I believe the main modules involved in the issue below are tm, tmx, and tsilo. Every call passing through the proxy leads to a small memory leak in the tm module - there is a large amount of "delayed free" memory cells from tm's internal hash table. At some point the shared memory runs out and Kamailio restarts. Using the "kamcmd corex.shm_summary" command I was able to see that the top users of shared memory are "tm: h_table.c: build_cell" and "core: core/sip_msg_clone.c: sip_msg_shm_clone" with the same allocation count. I experimented with removing different parts of the configuration and noticed that commenting out the "t_continue(...)" call in the "PUSHJOIN" route (see slide #22) prevents the leak from happening. Maybe something in that function is incrementing the reference counter to the hash table cell, but it is not decrementing the counter when done? I tried looking around the source code of the tm and tmx modules, but saw nothing suspicious. I also tried using gdb with a breakpoint in t_continue_helper (tm/t_suspend.c:166) hoping to see what else is accessing the htable cell, but was unable to find anything of use. Has someone encountered anything like this? Can you provide more directions on debuggin this? I can provide some bits of configuration, but an entire test setup would be rather difficult, unfortunately. Thank you for your time, Ivo

4 9

JSON RPC Error: LUMP_RPL_BODY already added!
by Asgaroth 11 Jun '18

11 Jun '18

Hi All, We are trying to query the json rpc server on our registrar for the contact of an aor, but we are seeing the following error(s) being displayed in the log when we query the location table: ERROR: <core> [core/data_lump_rpl.c:83]: add_lump_rpl2(): LUMP_RPL_BODY already added! ERROR: xhttp [xhttp_mod.c:410]: xhttp_send_reply(): Error while adding reply lump We are getting the aor details back in response from the rpc call, but the error's in the log are a little concerning and I cannot see where we are doing something wrong. As an example, the following curl request returns the correct response, but the above error is displayed in the log, Am I doing something wrong here, I cannot see what the issue is: curl --header 'Content-Type: application/json' --data-binary '{ "jsonrpc": "2.0", "method": "ul.lookup", "params": [ "location", "user(a)example.com" ], "id": 3 }' http://registrar.example.com/rpc A secondary question is, is there an upper limit on the size of the "id" parameter? This kamailio instance is v5.0.6. Any thoughts as to what this error means? Thanks

2 5

Combining lookup_branches() and t_(next|load)_contacts()
by Nathan Ward 09 Jun '18

09 Jun '18

Hi, About a year ago I posted this, but haven’t had much chance to follow up on it: https://lists.kamailio.org/pipermail/sr-users/2017-March/096337.html I’ve been doing some work on this issue (we worked around it until now), and have reduced the config right down to see where things are going wonky. The scenario I have, is inbound calls (to let’s say “A@domain") which I have aliased to two or more different numbers (let’s say “B@domain” and “C@domain”). Both B and C are registering, but are not always registered. I resolve the aliases with alias_db_lookup() (in my sample below, I use seturi() and append_branch() to avoid any confusion about where things may be going weird), then look them up in the location table with lookup_branches(). I then need to do t_load_contacts() and t_next_contacts(), as in some call scenarios I add a serial fork before or after the main call (pre-call announcements etc.). Then, I call t_relay(). This works great most of the time - however, if for example B is registered, but C is not registered, lookup_branches() notes that B is "Not found in usrloc”, and then t_load_contacts() seems to not realise that this isn’t usable, and it attempts to do a DNS lookup for the domain and so on, which I don’t really want it to be doing. Should lookup_branches() be removing a branch it can’t resolve? I would expect it to behave like that, anyway. Can I configure it to do that, or do I need to manually loop through them or something to make sure they resolved, and remove the ones that didn’t? I’ve tried swapping it around, so I call lookup_branches() after t_next_contacts() but the behaviour is the same. I imagine I can’t be the only person trying to do this - how have others made it work? Config sample: seturi('sip:a@domain'); append_branch('sip:b@domain'); xlog("L_DBG", "1 ds: [$ds]\n"); lookup_branches('location'); xlog("L_DBG", "2 ds: [$ds]\n"); t_load_contacts(); xlog("L_DBG", "3 ds: [$ds]\n"); t_next_contacts(); xlog("L_DBG", "4 ds: [$ds]\n"); -- Nathan Ward

1 1