#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [X] Commit message has the format required by CONTRIBUTING guide
- [X] Commits are split per component (core, individual modules, libs, utils, ...)
- [X] Each component has a single commit (if not, squash them into one commit)
- [X] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [ ] Small bug fix (non-breaking change which fixes an issue)
- [X] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [X] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
Introduce new function: `allow_register_include_port()` to be able to check the whole Contact header including port.
Example, register.deny content is:
```
ALL : "^sip:.*192.168.0.101:5062"
```
If the Contact is: "Contact: <sip:testuser1004@192.168.0.101:5062>" then this will check the Contact hf including port of it.
Otherwise if usual `allow_register()` function is used, then only the "testuser1004(a)192.168.0.101" will be taken into account, which will lead the regex to be failing and letting the check to pass through.
The func `allow_register_include_port()` works similarly as `allow_register()` except it checks Contact's port.
A separate function was created in order to not complicate things by introducing one more parameter to the
existing function `allow_register()`, which already takes a variable amount of parameters, so 1 or 2 parameters
(depending on if it is a "basename" or "allow-file, deny-file").
Documentation updated accordingly.
Additionally, "Register File Format" section has been added to the doc (to provide allow/deny file examples).
Full backwards compatibility is kept in place,
no need for users of the module to change anything in their configuration or kamailio script itself.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3846
-- Commit Summary --
* permissions: introduce func `allow_register_include_port()`
-- File Changes --
M src/modules/permissions/doc/permissions.xml (7)
M src/modules/permissions/doc/permissions_admin.xml (142)
M src/modules/permissions/permissions.c (56)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3846.patchhttps://github.com/kamailio/kamailio/pull/3846.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3846
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3846(a)github.com>
Module: kamailio
Branch: master
Commit: 534a35956b1a79598dcd2436248c5d7ce4e92da8
URL: https://github.com/kamailio/kamailio/commit/534a35956b1a79598dcd2436248c5d7…
Author: Donat Zenichev <dzenichev(a)sipwise.com>
Committer: Victor Seva <linuxmaniac(a)torreviejawireless.org>
Date: 2024-05-27T15:21:24+02:00
permissions: introduce func `allow_register_include_port()`
Introduce new function: `allow_register_include_port()`
to be able to check the whole Contact header including port.
Example, register.deny content is:
ALL : "^sip:.*192.168.0.101:5062"
If the Contact is: "Contact: <sip:testuser1004@192.168.0.101:5062>"
then this will check the Contact hf including port of it.
Otherwise if usual `allow_register()` function is used,
then only the "testuser1004(a)192.168.0.101" will be taken into
account, which will lead the regex to be failing and letting
the check to pass through.
The func `allow_register_include_port()` works similarly
as `allow_register()` except it checks Contact's port.
Full backwards compatibility is kept in place,
no need for users of the module to change anything in
their configuration or kamailio script itself.
---
Modified: src/modules/permissions/doc/permissions.xml
Modified: src/modules/permissions/doc/permissions_admin.xml
Modified: src/modules/permissions/permissions.c
---
Diff: https://github.com/kamailio/kamailio/commit/534a35956b1a79598dcd2436248c5d7…
Patch: https://github.com/kamailio/kamailio/commit/534a35956b1a79598dcd2436248c5d7…
Care to explain why this is wrong? Some DNS records that are fully in spec and have functioned for years without any problem now trigger filling the logs with these warnings.
Also, actually logging which record(s) are causing the issue and what would be needed to be done to fix them would be helpful, the hex address and message doesn't provide any useful info for the admin.
```
2024-05-27T10:01:04.263247+02:00 pc1 proxy1[335503]: WARNING: <core> [core/dns_cache.c:1700]: dns_get_related(): record not alone: 0x7f714ee28250 - type: 33
2024-05-27T10:01:04.269368+02:00 pc1 proxy1[335503]: WARNING: <core> [core/dns_cache.c:1700]: dns_get_related(): record not alone: 0x7f714ee28380 - type: 1
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/commit/d8a35b3b6c837b36779e232b65fce61…
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/commit/d8a35b3b6c837b36779e232b65fce61c3aa93387/142421279(a)github.com>
### Description
<!--
Explain what you did, what you expected to happen, and what actually happened.
- we migrated rtpengine urls from udp to websocket, so that kamailio is communicating to rtpengine overwebsocket to manage the offer and answer. however we observed that, tcp reciever process is consuming pkg memory as, traffic increased, but when traffic is idle then its not getting freed automatically. and eventually its consume all memory.
-
-
-->
### Troubleshooting
- as checked further we particulartly tcp reciever process was consuming pkg memory , then further we checked from corex pkg_sumary for that process id, and found that rtpengine: rtpengine.c: send_rtpp_command was consuming highest memory.
#### Reproduction
console rtpengine url with ws endpoint.
<!--
If the issue can be reproduced, describe how it can be done.
-->
this is reproducible, we can configure websocket in rtpengine module and then we can initate calls. and increase the number of calls over the period of time
#### Debugging Data
<img width="1399" alt="Screenshot 2024-03-06 at 4 30 16 PM" src="https://github.com/kamailio/kamailio/assets/115363081/0904892e-6a6e-4dc1-85…">
kamcmd pkg.stats
entry: 24
pid: 378355
rank: 17
used: 7467640
free: 24348320
real_used: 9206112
total_size: 33554432
total_frags: 66
desc: tcp receiver (generic) child=0
kamcmd corex.pkg_summary pid 378355
Mar 6 16:31:52 coreproxy-4 /usr/local/sbin/kamailio[378355]: ALERT: qm_sums: qm_sums(): count= 8075 size= 4638760 bytes from rtpengine: rtpengine.c: send_rtpp_command(3040)
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
(paste your output here)
version: kamailio 5.7.0 (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, MEM_JOIN_FREE, 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_BLOCKLIST, 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 on 01:04:28 Jan 25 2024 with gcc 9.4.0
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `lsb_release -a` and `uname -a`)
-->
```
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal
Linux coreproxy-4 5.15.0-1045-oracle #51~20.04.1-Ubuntu SMP Fri Sep 22 14:25:26 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3777
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3777(a)github.com>