<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### 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
**Use origin-host of CCR response as destination-host of subsequent CCR requests**
When connecting to a diameter node which using relay, it may load balance requests to multiple servers for handling. This change ensures that subsequent requests are sent to the same server.
**Honour AVP_Time_Quota_Threshold in CCR response**
Charging server indicates it want an interim update X number of seconds before all quota has been used.
**Add new modparam «strip_plus_from_e164»**
The existing formatitng routine check if it's a tel: or sip: uri, and sets E.164 or SIP according to that. If it's E.164, it strips "tel:" too. A subscription id with leading "+" is actually of type SIP.
I didn't want to make a breaking change here, so I introduced a new setting which fixes the behaviour.
**Moved subscription id formatting into a common function**
For more clean code, and one place to make further adjustments.
**Handle CCR response without AVP_Validity_Time**
If missing, various places in the module reported immediate expire.
**Handle IMS_RAR (Re-auth) request from charging server**
Typical scenario is that there's a missing interim update, and the server want to check if the session is still alive. At reception we try a lookup and if found, schedule a new request.
**Handle IMS_ASR (Abort) request from charging server**
Similar handling as for re-auth, but for server-initiated termination of the call.
**Fixed issue with signed/unsigned int related to check for Expires header**
cscf_get_expires_hdr() returns signed (-1 for not found), while that value was added
to the outgoing diameter request unsigned. That again resulted in an Expires AVP with
a really large value, and was rejected by the charging server.
Most probably cscf_get_expires_hdr() should be changed to return unsigned since the value theoretical can be that big, but since that is a common function for the ims modules it would require more testing than I'm capable of right now.
**Use str_dup() and str_free() from ims_getters instead of locally defined**
Those were needed more places.
--
I'm a little bit unsure about updating a string allocated in shm, where the length is changed (look in ims_ro.c, credit_control_session_callback()). Is the correct way to do a shm_free() and then reallocate, or is there a more simple way of doing it?
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3640
-- Commit Summary --
* cdp: Add support for re-auth on ro sessions initiated from charging server
* ims_charging: Various changes to make module compatible to other charging servers
-- File Changes --
M src/modules/cdp/acctstatemachine.c (2)
M src/modules/cdp/diameter_code_avp.h (2)
M src/modules/cdp/peerstatemachine.c (8)
M src/modules/cdp/session.c (2)
M src/modules/ims_charging/Ro_data.c (40)
M src/modules/ims_charging/Ro_data.h (5)
M src/modules/ims_charging/ccr.c (8)
M src/modules/ims_charging/config.h (1)
M src/modules/ims_charging/dialog.c (18)
M src/modules/ims_charging/doc/ims_charging_admin.xml (20)
M src/modules/ims_charging/ims_charging_mod.c (59)
M src/modules/ims_charging/ims_ro.c (234)
M src/modules/ims_charging/ims_ro.h (3)
M src/modules/ims_charging/ro_db_handler.c (43)
M src/modules/ims_charging/ro_db_handler.h (5)
M src/modules/ims_charging/ro_session_hash.c (45)
M src/modules/ims_charging/ro_session_hash.h (6)
M src/modules/ims_charging/ro_timer.c (8)
M utils/kamctl/mysql/ims_charging-create.sql (3)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3640.patchhttps://github.com/kamailio/kamailio/pull/3640.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3640
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3640(a)github.com>
### Description
I use debian 11 and Kamailio 5.6.x
modparam("htable", "htable", "callpush=>size=10;autoexpire=86400;dbtable=callpush;dbmode=1")
I can store the values in the table, but if I shutdown kamailio, the current values are not stored in the table.
#### Reproduction
Use a htable and dbtable and dbmode=1 and shutdown kamailio.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3536
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3536(a)github.com>
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for feature requests.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-users.lists.kamailio…
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-dev.lists.kamailio.o…
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If you submit a feature request (or enhancement) add the description of what you would like to be added.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
The current issue revolves around the absence of username support within the NDB REDIS KAMALIO framework when dealing with Redis, particularly concerning the Redis and Sentinel components. While Redis inherently offers the capability to utilize both usernames and passwords during authentication, this capability is not currently extended to the NDB REDIS KAMALIO setup.
As a result, when attempting to establish connections to Redis instances through NDB REDIS KAMALIO, there is no provision for providing a username as part of the authentication process. Instead, the framework only accommodates the usage of passwords for authentication. This stands in contrast to Redis, which permits the inclusion of both usernames and passwords for enhanced security measures.
Consequently, the limitation within NDB REDIS KAMALIO can hinder organizations seeking to ensure comprehensive security practices, especially when the requirement is to employ both usernames and passwords for authentication. This divergence between the authentication capabilities of Redis and NDB REDIS KAMALIO can potentially compromise security standards and hinder compatibility with certain authentication setups.
To address this issue, it would be essential for the development team behind NDB REDIS KAMALIO to enhance the framework's capabilities by incorporating support for username-based authentication in addition to passwords. This alignment with Redis's authentication model would ensure that organizations can confidently implement secure data interactions while maintaining consistency with established security policies
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Expected behavior
The expected behavior entails an improvement within the NDB REDIS KAMALIO framework to support both usernames and passwords for authentication when interacting with Redis instances, particularly in the Redis and Sentinel components. This enhancement would bring NDB REDIS KAMALIO in line with Redis's native authentication capabilities, where both usernames and passwords are accepted during the authentication process.
Upon implementing this improvement, users of NDB REDIS KAMALIO should be able to configure their connections by providing both a username and a password as part of the authentication details. This allows NDB REDIS KAMALIO to establish connections to Redis instances that require both authentication credentials, thereby enhancing security and ensuring compatibility with various authentication setups.
By incorporating support for usernames in addition to passwords, NDB REDIS KAMALIO can accommodate organizations that require comprehensive security measures, especially in scenarios where username-based authentication is mandated. This alignment with Redis's authentication model would enable organizations to effectively collect, manage, and interact with data while adhering to established security policies.
In summary, the expected behavior is that NDB REDIS KAMALIO should be upgraded to offer support for usernames and passwords during authentication, mirroring Redis's capabilities. This enhancement ensures a consistent and secure approach to data interactions and supports various authentication requirements within Redis environments
#### Actual observed behavior
The current actual behavior is that NDB REDIS KAMALIO does not have the capability to accept usernames as part of the authentication process when connecting to Redis instances, specifically in both the Redis and Sentinel components. While Redis itself allows for the usage of both usernames and passwords for authentication, this feature is not currently integrated into the NDB REDIS KAMALIO framework.
As a result, when configuring connections to Redis instances using NDB REDIS KAMALIO, there is no provision to include a username alongside the authentication details. The framework only accommodates the use of passwords for authentication purposes. This deviation from Redis's authentication model could lead to compatibility issues with certain authentication setups, particularly those that mandate the use of both usernames and passwords.
In essence, the actual behavior is that NDB REDIS KAMALIO falls short of aligning with Redis's authentication capabilities, thereby potentially hindering secure data interactions and limiting compatibility with certain security policies. Users attempting to adhere to comprehensive authentication practices may face challenges when utilizing NDB REDIS KAMALIO due to its inability to support usernames during authentication.
To address this actual behavior, it would be necessary to enhance NDB REDIS KAMALIO's capabilities to include support for both usernames and passwords during the authentication process. This enhancement would ensure that organizations can confidently utilize NDB REDIS KAMALIO while maintaining the security standards and authentication requirements necessary for their Redis environments.
#### Debugging Data
```
(paste your debugging data here)
```
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your log messages here)
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your sip traffic here)
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a improvement.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
(paste your output here)
```
* **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 `uname -a`)
-->
```
(paste your output here)
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3552
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3552(a)github.com>
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-users.lists.kamailio…
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-dev.lists.kamailio.o…
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
Currently, kamailio NDB Redis integration with Sentinel does not offer support for password authentication, leading to potential security concerns in our system. As a result, we are unable to ensure the desired level of protection for sensitive data stored in Redis.
*Expected Behavior:*
We expect Kamailio to allow the configuration of password authentication for Sentinel in the NDB Redis integration, enabling a secure and password-protected connection to the Redis instances.
*Proposed Solution:*
To address this issue, we recommend implementing a feature that enables password authentication for the Sentinel-based NDB Redis connections. This improvement will provide an added layer of security, ensuring that only authorized users can access the Redis instances.
*Impact:*
The absence of password authentication support poses a security risk, making our system vulnerable to potential unauthorized access and data breaches. Implementing this enhancement will safeguard sensitive information and strengthen our Redis integration's security framework.
Note: as of now NDB REDIS support redis authentication using password
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Troubleshooting
#### Reproduction
Steps to Reproduce:*
1. Attempt to configure password authentication for Sentinel in kamailio NDB Redis integration.
ex:
modparam("ndb_redis", "server", "name=srvZ;sentinel_group=group_name;sentinel_master=1;sentinel=1.2.3.4:26379;sentinel=1.2.3.5:26379";pass=mypassword")
*It is failed to connect the sentinel *
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### Debugging Data
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
-->
```
(paste your debugging data here)
```
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your log messages here)
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your sip traffic here)
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
(paste your output here)
```
* **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`)
-->
```
(paste your output here)
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3530
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3530(a)github.com>
### Description
Newer rtpengine versions support manipulating SDP "a=" lines directly. Although kamailio is quite versatile when it comes to editing SIP message body, this functionality is often rather frail, especially when forking and having to use msg_apply_changes several times. I believe it would be beneficial to be able to offload such functionality to rtpengine, especially if one wants to apply different manipulations per outgoing branch.
### Expected behavior
There should be a way to issue rtpengine ng-control protocol commands compatible with the sdp-attr dictionary syntax.
#### Actual observed behavior
Currently sdp-attr tokens are not properly evaluated. For example, **doing**:
> rtpengine_manage("ICE=remove rtcp-mux-demux trust-address replace-origin replace-session-connection replace-SDP-version direction=internal direction=external sdp-attr-audio-substitute=$avp(fmtp_line) sdp-attr-audio-substitute=fmtp:101 0-15");
_[NOTE: $avp(fmtp_line) seems to expand in empty string here, which is a config error, but it doesn't affect the syntax demonstration in this example IMO]_
**results in**:
```
{
"supports": [ "load limit" ],
"sdp": "...",
"ICE": "remove",
"sdp-attr-audio-substitute": "",
"sdp-attr-audio-substitute": "fmtp:101",
"direction": [ "internal", "external" ],
"flags": [ "trust-address", "0-15" ],
"replace": [ "origin", "session-connection", "SDP-version" ],
"rtcp-mux": [ "demux" ],
"call-id": "...",
"received-from": [ "IP4", "..." ],
"from-tag": "...",
"to-tag": "...",
"command": "answer"
}
```
### Possible Solutions
Support the special syntax of sdp-attr as documented here: https://github.com/sipwise/rtpengine/blob/master/docs/ng_control_protocol.md
Here's one way to do it (I guess).
In order to get this:
```
"sdp-attr" :
{
"audio" :
{
"add" : [ "ptime:20", "sendrecv" ],
"substitute": [["fmtp:101 0-15" , "fmtp:126 0-16" ]]
},
"video":
{
"remove" : [ "rtpmap:101 telephone-event/8000" ]
},
"none" :
{
"substitute": [[ "sendrecv" , "sendonly" ], [ "ptime:20" , "ptime:40" ]]
}
}
```
Use a syntax similar to the following:
> rtpengine_manage("... sdp-attr-audio-add=ptime:20 sdp-attr-audio-add=sendrecv sdp-attr-audio-substitute=fmtp:101 0-15 sdp-attr-audio-substitute=fmtp:101 0-16 sdp-attr-video-remove=rtpmap:101 telephone-event/8000 sdp-attr-none-substitute=sendrecv sdp-attr-none-substitute=sendonly sdp-attr-none-substitute=ptime:20 sdp-attr-none-substitute=ptime:40 ...");
It's not very pretty, but it could work. Caveats:
* How to handle whitespace (e.g. there's a space in "fmtp:101 0-15" and in "rtpmap:101 telephone-event/8000" )
* substitute commands must always be in pairs, data type is a list of lists containing exactly two items as value in "substitute" key
Unfortunately my C skills are not up to this task, but if I can provide any other kind of help please let me know. Thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3509
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3509(a)github.com>
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### 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, ...)
- [ ] 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:
<!-- 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
This PR adds support for $hfl(Diversion)[] and $hflc(Diversion).
This parse_diversion.c was inspired by [parse_pai_ppi.c](https://github.com/kamailio/kamailio/blob/master/src/core/…. I am not sure if it's breaking the existing implementation and usage. I believe it does not.
During some experimentation with the hfl(name)[-1], I encountered weird behavior with negative indexing for the already supported headers like Via, Route, and Contact. -1 yields null and -2 yields the last one and so on. Separate PR can be introduced if necessary.
Any feedback is welcome.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3650
-- Commit Summary --
* parser: Extend diversion for multiple bodies
* pv: Add hfl and hflc support for Diversion header
-- File Changes --
M src/core/parser/parse_diversion.c (149)
M src/core/parser/parse_diversion.h (10)
M src/modules/pv/pv_core.c (175)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3650.patchhttps://github.com/kamailio/kamailio/pull/3650.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3650
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3650(a)github.com>