[sr-dev] [kamailio/kamailio] lcr: source port check for from_any_gw() and from_gw(). (#2832)

[zenichev]

A simple change, which allows to check, if a coming request matches
not only by an IP address and a transport protocol,
but also using the source port of a request.

Improvements are done for the following functions of the lcr module:
- from_any_gw()
- from_gw()

Back compatibility provided, hence it does not affect already existing behavior.
You can view, comment on, or merge this pull request online at:

  https://github.com/kamailio/kamailio/pull/2832

-- Commit Summary --

  * lcr: source port check for from_any_gw() and from_gw().

-- File Changes --

M src/modules/lcr/doc/lcr_admin.xml (31)
M src/modules/lcr/lcr_mod.c (116)

-- Patch Links --

https://github.com/kamailio/kamailio/pull/2832.patch
https://github.com/kamailio/kamailio/pull/2832.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2832
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] lcr: source port check for from_any_gw() and from_gw(). (#2832)

[zenichev]

@zenichev pushed 1 commit.

d8583d6ce1748c1ac8494616fced507b01dd4375  lcr: remove excessive checks for the 
'src_port' accuracy


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/kamailio/kamailio/pull/2832/files/14e6fc80b3d2389567c73c4a2196bf8e6d92d8d2..d8583d6ce1748c1ac8494616fced507b01dd4375
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] lcr: improve binary search to support a match including src port (#2859)

[zenichev]

 Pre-Submission Checklist
- [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
- [X] Small bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)

 Checklist:
- [ ] PR should be backported to stable branches
- [X] Tested changes locally
- [ ] Related to issue # (replace  with an open issue number)

 Description
Improve binary search in the lcr module and add a possibility
to do a matching not only based on an IP address of a GW, but also using a 
source port.

When a possibility to use 'src_port' parameter in from_gw() and 
from_any_gw()
was introduced here: 14e6fc80b3d2389567c73c4a2196bf8e6d92d8d2
the bsearch() remained untouched, and hence the matching (iteration through 
existing GWs)
is now done only based on an IP address.

This leads to the issue, when there are more than one GW with the same IP 
address in gws table,
and from_gw() and from_any_gw() functions are used with the 'src_port' 
parameter,
it can happen that a wrong GW is picked out by bsearch() from gws table 
(lcr_gw) and
a check by from_gw() and from_any_gw() returns False.

Hence the matching based on IP address and source port is required for 
bsearch(),
when from_gw() and from_any_gw() functions are used with the 'src_port' 
parameter.

This means backwards compatibility is still present (when one uses functions 
without 'src_port').
You can view, comment on, or merge this pull request online at:

  https://github.com/kamailio/kamailio/pull/2859

-- Commit Summary --

  * lcr: improve binary search to support a match including src port

-- File Changes --

M src/modules/lcr/lcr_mod.c (37)

-- Patch Links --

https://github.com/kamailio/kamailio/pull/2859.patch
https://github.com/kamailio/kamailio/pull/2859.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2859
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] lcr: improve binary search to support a match including src port (#2859)

[zenichev]

> After the binary match change, is it so that there is no need to change this 
> test?
> 
> ```
> /* Store tag and flags and return result */
>   if((res != NULL)
>   && ((transport == PROTO_NONE) || 
> (res->transport_code == transport))
>   && ((src_port == 0) || (res->port == 
> src_port))) {
> ```

Yes, you're right. Since the updated bsearch() already has ports comparison,
I think the following part looks excessive (doesn't break anything though):
`&& ((src_port == 0) || (res->port == src_port))) {`

I'll remove it.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2859#issuecomment-922425300___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] lcr: improve binary search to support a match including src port (#2859)

[zenichev]

@zenichev pushed 1 commit.

aa8d3ed4fe20efbd22db3b0b01a655789afa8818  lcr: remove excessive conditional 
check in do_from_gw()


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/kamailio/kamailio/pull/2859/files/470fd5b8bedca56efcc5e6aa0225089fe3857ac9..aa8d3ed4fe20efbd22db3b0b01a655789afa8818
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] lcr: improve the search for GW when IP address and src_port are used (#2876)

[zenichev]

 Pre-Submission Checklist



- [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
- [X] Small bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)

 Checklist:

- [ ] PR should be backported to stable branches
- [X] Tested changes locally
- [ ] Related to issue # (replace  with an open issue number)

 Description

It has been noticed, that after a list of contributions into lcr:
* 14e6fc80b3d2389567c73c4a2196bf8e6d92d8d2
* d8583d6ce1748c1ac8494616fced507b01dd4375
* 470fd5b8bedca56efcc5e6aa0225089fe3857ac9
* aa8d3ed4fe20efbd22db3b0b01a655789afa8818

the gateways matching when a search is being done based on
the IP address and the src_port (through the array of GWs **with the same IP**)
works, but not fully correct.

It is only related to the usage with the third parameter 'src_port',
when calling from_gw() and from_any_gw(), and, only when the search
is done through the gateways array, which have **the same IP address**
,but different ports (let's say one has 30 GWs with the same IP in the 
lcr_gw).
If gateways have different IPs, the issue is not catchable.

The problem is in the algorithm used for matching based on
two objects (ip_addr and src_port) - the binary search.
It's not fully suitable for a search based on two (or more) objects.

The binary works completely fine, when only one object is used for searching,
but works not fully correct when the search is based on a comparison
of two (or more) objects. A division happening based on the value of
the first object, gives a chance that the second object will never
be found in the current half being looked up.

This commit concerns switching to a full cycling through the array of
gateways of the same lcr_id, and gives a proper work of the do_from_gw().

The slight drawback of the new method is that we have to do a cycling
through the whole array of GWs **of the same lcr_id**, but on the other hand
it is much more efficient than trying to build up a matching using binary search
based on two objects (ip_addr and src_port) being used for comparison.

If we had to build this using bsearch() as well, then we would have to:
- first prepare a sorted array of the gateways with the same IP (sorted in 
terms of ports)
  ,which already means with have to go through the whole GWs array to catch all 
needed GWs ;
- do a bsearch() based on src_port only (using previously prepared sorted 
array) ;
Which looks similar **to the full cycling** in terms of CPU resource 
consumption.
You can view, comment on, or merge this pull request online at:

  https://github.com/kamailio/kamailio/pull/2876

-- Commit Summary --

  * https://github.com/kamailio/kamailio/pull/2876/commits/7f02e89622d6e9294906bebb8ceda76b25072ba4";>lcr:
 improve the search for GW when both IP address and src_port are used

-- File Changes --

M src/modules/lcr/lcr_mod.c (39)

-- Patch Links --

https://github.com/kamailio/kamailio/pull/2876.patch
https://github.com/kamailio/kamailio/pull/2876.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2876
___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] Cnxcc doesn't update values in redis (#1387)

[zenichev]

### Description



### Troubleshooting

 Reproduction



 Debugging Data



```
(paste your debugging data here)
```

 Log Messages



```
(paste your log messages here)
```

 SIP Traffic



```
(paste your sip traffic here)
```

### Possible Solutions



### Additional Information

  * **Kamailio Version** - output of `kamailio -v`

```
version: kamailio 5.0.4 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, 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_LISTEN 16, 
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 17:22:52 Nov 27 2017 with gcc 5.4.0

```

* **Operating System**:



```
Debian stretch
Linux machine_name_here SMP Tue Dec 5 10:49:06 UTC 2017 x86_64 x86_64 x86_64 
GNU/Linux
```


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1387___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] Cnxcc doesn't update values in redis (#1387)

[zenichev]

Sorry for the delayed response.
Problem is solved by recompiling the cnxcc module.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1387#issuecomment-366190928___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] db_redis: Implement db_redis generic db driver (#1432)

[zenichev]

The relevant question - how to implement authentication while connecting to 
redis storage?
I read this document: 
https://kamailio.org/docs/modules/devel/modules/db_redis.html
and didn't find any reference in it.

As I understood we use following syntax to connect to the redis db:
redis://[username]@host:port/database

But authentication capability is not provided as I can see.

Of course there is an excellent module named ndb_redis.
But my main goal is to perform authentication with cnxcc module, which is not 
able to do that (Carlos Ruiz Díaz will add this possibility later?).

Please correct me if I'm wrong.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/1432#issuecomment-367265258___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] db_redis: Implement db_redis generic db driver (#1432)

[zenichev]

Well, for that moment it doesn't work.

My configuration is as follows:

#!define DBURL_CNXCC "redis://here_my_passw...@redis.domain.com:6379/1"
loadmodule "db_redis.so"
modparam("db_redis", "schema_path", "/usr/share/kamailio/db_redis/kamailio")

modparam("cnxcc", "redis", DBURL_CNXCC)

I think this is wrong way to do that.
cnxcc module uses redis db as htable and stores real-time values (like credit, 
call duration etc.) that exist only when call is up for certain customer, then 
it drops whole key.

Should I use: 'modparam("db_redis", "keys"...'  ?
Or db_redis is to be improved to work with cnxcc? (cuz it uses not "db_url" 
modparam but "redis" modparam).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/1432#issuecomment-368041757___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] db_redis: Implement db_redis generic db driver (#1432)

[zenichev]

@miconda - as I mentioned above, I need working authentication for cnxcc (that 
is not able to work with authentication).
So that, I'm trying to find a way to do that, this time by db_redis.
Do you think this is a wrong way?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/1432#issuecomment-368045881___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Re: [sr-dev] [kamailio/kamailio] db_redis: Implement db_redis generic db driver (#1432)

[zenichev]

@miconda Ok I understood it clearly. Thank you for your answer.
Will try to start discussion on sr-users list.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/1432#issuecomment-368049038___
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

[sr-dev] [kamailio/kamailio] rtpengine: add flags processing on the daemon side (PR #3788)

[Donat Zenichev via sr-dev]

 Pre-Submission Checklist



- [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:

- [ ] PR should be backported to stable branches
- [X] Tested changes locally
- [ ] Related to issue # (replace  with an open issue number)

 Description

Introduce a versatile behavior of the rtpengine module
in terms of ability to parse flags on rtpengine side,
instead of module. Previous behavior is also kept (so backwards compatibility).

General points:
 - rtpengine daemon supports rtpp flags processing from now on
 - module still provides in the bencode (when calling daemon):
   call-id, to/from tags, viabranch (so identification call data)
 - even though the module's interface is updated,
   a backwards compatibility is given, so no obligatory changes
   from kamailio script users required
 - each rtpengine module's function where it's reasonable to use rtpp 
flags
   as a parameter, now is able to get a third parameter `viabranch`,
   which is used to detect, which approach to use (older/newer):
   - without the viabranch - older one used
   - with the viabrnach - new one used, so rtpp flags parsing on
 rtpengine side

The reason why the `via-branch` has been selected as a point of behavior
differentiation is that currently it's only given via option flags list 
(raw string),
meanwhile with a newer behavior option flags will not be parsed by the module.
Since the module still has to provide all the basic identifiers, such as:
call-id, From/To tags and via-branch, via-branch now is moved to a separate 
parameter,
and gives to the module a clue a newer behavior is to be applied.

The goal (for the future) is to deprecate processing of option flags
on the module side and only parse them using rtpengine.
This brings a list of benifits, such as:
 - no need to keep in sync rtpengine and module (for specific flags)
 - support of different rtpp flag string formats (raw), so that,
   for example, kamailio script users can use plain text or
   bencode dictionary like format, when providing flags from
   the kamailio script

Current change is only applicable with rtpengine versions equal or later than 
mr12.3
Backwards compatibility provided, so users are not forced to change anything.
You can view, comment on, or merge this pull request online at:

  https://github.com/kamailio/kamailio/pull/3788

-- Commit Summary --

  * rtpengine: add flags processing on the daemon side
  * rtpengine: update documentation in regards of flags processing

-- File Changes --

M src/modules/rtpengine/doc/rtpengine.xml (8)
M src/modules/rtpengine/doc/rtpengine_admin.xml (45)
M src/modules/rtpengine/rtpengine.c (847)

-- Patch Links --

https://github.com/kamailio/kamailio/pull/3788.patch
https://github.com/kamailio/kamailio/pull/3788.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3788
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] rtpengine: add flags processing on the daemon side (PR #3788)

[Donat Zenichev via sr-dev]

@zenichev pushed 1 commit.

c281bcd682faac379437a2bd240ab69f1383  rtpengine: add flags processing on 
the daemon side

-- 
View it on GitHub:
https://github.com/kamailio/kamailio/pull/3788/files/e2c1a0f57201d04e437e02ddb1cc7dd1ab1bbc2e..c281bcd682faac379437a2bd240ab69f1383
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] rtpengine: add flags processing on the daemon side (PR #3788)

[Donat Zenichev via sr-dev]

@zenichev pushed 2 commits.

3d6905638106f4b318a8855c1ba3febd5fcfeb61  rtpengine: add flags processing on 
the daemon side
3a92ff79115ee4e27f02c4f853ccca7a79ba95a2  rtpengine: update documentation in 
regards of flags processing

-- 
View it on GitHub:
https://github.com/kamailio/kamailio/pull/3788/files/24e8c7d11f6b6a98b30f9ede1b0fad7982896745..3a92ff79115ee4e27f02c4f853ccca7a79ba95a2
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] [kamailio/kamailio] permissions: introduce func `allow_register_include_port()` (PR #3846)

[Donat Zenichev via sr-dev]

 Pre-Submission Checklist



- [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:

- [ ] PR should be backported to stable branches
- [X] Tested changes locally
- [ ] Related to issue # (replace  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: 
" then this will check the 
Contact hf including port of it.

Otherwise if usual `allow_register()` function is used, then only the 
"testuser1004@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.patch
https://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 (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] permissions: introduce func `allow_register_include_port()` (PR #3846)

[Donat Zenichev via sr-dev]

@mtirpak can you pleae have a look?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3846#issuecomment-2109971461
You are receiving this because you are subscribed to this thread.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org

[sr-dev] Re: [kamailio/kamailio] permissions: introduce func `allow_register_include_port()` (PR #3846)

[Donat Zenichev via sr-dev]

@henningw maybe you could have a look?
We've tested that on our systems, and actually use it already in our latest 
master.

Regards,
Donat

-- 
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3846#issuecomment-2122061493
You are receiving this because you are subscribed to this thread.

Message ID: ___
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org