- fixed log message in MAR Async CDP callback
- fixed executing cfg_action after sending MAR Diameter request
- cfg_action is the callback parameter of the ims_www_challenge function
<!-- 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)
- [ ] 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
- [ ] Tested changes locally
- [ ] Related to issue #4205 (replace XXXX with an open issue number)
#### Description
Based on the description in issue #4205, this PR will fix a bug in ims_auth module related to MAR Diameter request callbacks, by replacing the call to t_continue function with t_continue_skip_timer, after the MAR request is sent, the control will successfully move to the cfg action in Kamailio scripts. Just like what we already have in ims_registrar_scscf module, using t_continue_skip_timer instead of t_continue cause the transaction to be found and resumed.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4206
-- Commit Summary --
* ims_auth: replaced t_continue_skip_timer with t_continue in cxdx_mar.c
-- File Changes --
M src/modules/ims_auth/cxdx_mar.c (6)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4206.patchhttps://github.com/kamailio/kamailio/pull/4206.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4206
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4206(a)github.com>
nochnoi82 created an issue (kamailio/kamailio#4243)
Greetings folks.
Need your help or conclusion.
Debian 12
Kamailio 6.0.1 (Open source installed)
Init script and systemd script were applied.
kamctl start (/usr/local/sbin)
ERROR: PID file /var/run/kamailio.pid does not exist -- Kamailio start failed
kamailio start (/usr/local/sbin)
error: 'start' is not a supported argument
error: stopping kamailio ...
sudo journalctl -xeu kamailio
ERROR: db_mysql [km_my_con.c:219]: db_mysql_new_connection(): driver error: Access denied for user 'kamailio'@'localhost' (using password: YES)
May 15 11:50:54 zaks-sbc01-op /usr/local/sbin/kamailio[53616]: ERROR: <core> [lib/srdb1/db.c:326]: db_do_init2(): could not add connection to the pool
May 15 11:50:54 zaks-sbc01-op /usr/local/sbin/kamailio[53616]: ERROR: usrloc [dlist.c:848]: register_udomain(): failed to open database connection
May 15 11:50:54 zaks-sbc01-op /usr/local/sbin/kamailio[53616]: ERROR: registrar [registrar.c:773]: domain_fixup(): failed to register domain
May 15 11:50:54 zaks-sbc01-op /usr/local/sbin/kamailio[53616]: ERROR: <core> [core/route.c:1195]: fix_actions(): fixing failed (code=-1) at cfg:/usr/local/etc/kamailio/kamailio.cfg:750
May 15 11:50:54 zaks-sbc01-op /usr/local/sbin/kamailio[53616]: ERROR: <core> [core/rvalue.c:3816]: fix_rval_expr(): failure in cfg at line: 750 col: 22
May 15 11:50:54 zaks-sbc01-op /usr/local/sbin/kamailio[53616]: ERROR: <core> [core/rvalue.c:3816]: fix_rval_expr(): failure in cfg at line: 750 col: 22
May 15 11:50:54 zaks-sbc01-op /usr/local/sbin/kamailio[53616]: ERROR: <core> [core/route.c:1195]: fix_actions(): fixing failed (code=-1) at cfg:/usr/local/etc/kamailio/kamailio.cfg:753
Kamailio acts as proxy server only.
What did i miss?
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4243
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4243(a)github.com>
tianhao98 created an issue (kamailio/kamailio#4237)
### Description
I used the xhttp module to add a fake Via header to handle HTTP requests in Kamailio. But it will produce the following error
```
104(113) ERROR: <core> [core/parser/parse_uri.c:1417]: _parse_ruri(): bad uri </metrics>
104(113) ERROR: <core> [core/parser/parse_uri.c:1455]: parse_orig_ruri(): parse orig ruri failed
104(113) ERROR: pv [pv_core.c:355]: pv_get_ouri_attr(): failed to parse the R-URI
```
### Troubleshooting
#### Debugging Data
Set up a Kamailio server with the xhttp module enabled.
```
loadmodule "xhttp.so"
```
#### Log Messages
```
104(113) ERROR: <core> [core/parser/parse_uri.c:1417]: _parse_ruri(): bad uri </metrics>
104(113) ERROR: <core> [core/parser/parse_uri.c:1455]: parse_orig_ruri(): parse orig ruri failed
104(113) ERROR: pv [pv_core.c:355]: pv_get_ouri_attr(): failed to parse the R-URI
```
#### SIP Traffic
N/A — this is a pure HTTP request triggering the SIP parser.
### Additional Information
```
root@kamailio-60-bot-67d564c54c-xj97x:/# kamailio -V
version: kamailio 6.0.1 (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_SEND_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 8.3.0
```
* **Operating System**:
```
root@kamailio-60-bot-67d564c54c-xj97x:/# uname -a
Linux kamailio-60-bot-67d564c54c-xj97x 5.4.119-19.0009.28 #1 SMP Thu May 18 10:37:10 CST 2023 x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4237
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4237(a)github.com>
Pandi1981 created an issue (kamailio/kamailio#4208)
We are facing an issue while using TOPOS in Kamailio P-CSCF (running under Docker).
Kamailio version: 6.0.0
operating system: "10 (buster)"
**Call Flow & Issue Description:**
Note: Public IP and Private IP mapping using the below configuration.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
listen=udp:LOCAL_IP:5060 name "internal"
listen=udp:LOCAL_IP:6080 advertise PUBLIC_IP:6080 name "external"
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
**Call Flow (INVITE):**
A-Party --> Kamailio P-CSCF (Public IP) --> Kamailio P-CSCF (Private IP) --> Kamailio S-CSCF (Private IP)
B-Party <-- Kamailio P-CSCF (Public IP) <-- Kamailio P-CSCF (Private IP) <-- Kamailio S-CSCF (Private IP)
Everything works correctly up to the point where the 200 OK is received by the A-Party. However, when the A-Party sends the ACK, it is received by the Kamailio P-CSCF but is not forwarded to the B-Party.
Upon investigation, we found that when Kamailio receives the ACK from the A-Party, the rr (Record-Route) module fails to recognize its own Route header and thus falls back to strict routing instead of performing loose routing. This results in an incorrect rewrite of the Request-URI of the ACK, causing it to fail to reach the B-Party. Essentially, the Route header is not popped as expected and the ACK routing breaks.
TOPOS module is configured as follows:
loadmodule "topos_redis.so"
loadmodule "ndb_redis.so"
loadmodule "topos.so"
modparam("ndb_redis", "server", "name=tps;addr=127.0.0.1;port=6379;db=0")
modparam("topos", "storage", "redis")
modparam("topos_redis", "serverid", "tps")
modparam("topos", "rr_update", 1)
modparam("topos", "contact_mode", 1)
modparam("topos", "xavu_field_a_contact", "a_contact")
modparam("topos", "xavu_field_b_contact", "b_contact")
modparam("topos", "xavu_cfg", "tps")
Please guide us how to achieve and what we are doing wrong.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4208
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4208(a)github.com>