### Description
I noticed an issue regarding loose_route() when using Topos module.
My architecture is the following:
```
Client (behind NAT or not) ------> Kamailio (Access SBC) -----------> Kamailio (Interconnect SBC) -----------> Carrier
```
Kamailio Access SBC is listening on 2 interfaces:
```
Public interface : udp:A.A.A.A:5060
Core interface : udp:B.B.B.B:5060
```
Kamailio Interconnect SBC is listening on 2 interfaces:
```
Core interface : udp:C.C.C.C:5060
Carrier-side interface : udp:D.D.D.D:5060
```
TOPOS is configured only on second kamailio box (Interconnect SBC).
Record routing is used on both kamailios.
TOPOS module is configured as follows:
```
modparam("ndb_redis", "server", "name=srv1;addr=127.0.0.1;port=6379")
modparam("topos_redis", "serverid", "srv1")
modparam("topos", "storage", "redis")
modparam("topos", "contact_mode", 1)
modparam("topos", "cparam_name", "id")
modparam("topos", "rr_update", 1)
```
RR module is configured as follows:
```
modparam("rr", "enable_full_lr", 1)
modparam("rr", "append_fromtag", 1)
modparam("rr", "enable_double_rr", 1)
```
For an incomoing INVITE (direction: client to carrier) all is fine and topos can strip headers on bleg and insert the cookie on bleg contact as a param.
When Callee sends a BYE or re-INVITE, topos inserts route headers in aleg as shown in the next trace: (BYE as received from the carrier on the carrier-side interface D.D.D.D)
```
BYE sip:D.D.D.D:5060 SIP/2.0
Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bKrdhsvc001omkvssqvfk0sd0185mt1.1
From: <sip:+33123456789@my-carrier-domain;transport=UDP;user=phone>;tag=SD69ao497-1472568650-1635329820043
To: <sip:+33987654321@my-own-domain;transport=UDP;user=phone>;tag=3ab10616
Call-ID: NjZjMDgyMGMxNzdkN2FhYmJlYzQyYjA5YWIzZThmZmI.
CSeq: 547381883 BYE
Max-Forwards: 64
Content-Length: 0
Route: <sip:D.D.D.D;r2=on;lr=on;ftag=3ab10616>,<sip:C.C.C.C;r2=on;lr=on;ftag=3ab10616>
Route: <sip:B.B.B.B;r2=on;lr=on;ftag=3ab10616;dlg_id=426.26c2>,<sip:A.A.A.A;r2=on;lr=on;ftag=3ab10616;dlg_id=426.26c2>
P-SR-XUID: atpsh-617925e5-82a5-1
```
Topos on the kamailio interconnect handles the BYE/re-INVITE and forward it to the second interface C.C.C.C as shown in the following trace:
```
BYE sip:A.A.A.A;r2=on;lr=on;ftag=3ab10616;dlg_id=426.26c2 SIP/2.0
Via: SIP/2.0/UDP 185.164.213.110;branch=z9hG4bKbd7.ab692eeb60369aa3a5e07f6b63cc9dd7.0
From: <sip:+33123456789@my-carrier-domain;transport=UDP;user=phone>;tag=SD69ao497-1472568650-1635329820043
To: <sip:+33987654321@my-own-domain;transport=UDP;user=phone>;tag=3ab10616
Call-ID: NjZjMDgyMGMxNzdkN2FhYmJlYzQyYjA5YWIzZThmZmI.
CSeq: 547381883 BYE
Max-Forwards: 63
Content-Length: 0
Route: <sip:C.C.C.C;r2=on;lr=on;ftag=3ab10616>
Route: <sip:B.B.B.B;r2=on;lr=on;ftag=3ab10616;dlg_id=426.26c2>
Contact: <sip:+33123456789@10.3.60.45;id=atpsh-617925e5-82a5-1>
```
When the BYE/re-INVITE request reaches the C.C.C.C interface, it is then forwarded directly to the ruri sip:A.A.A.A.
Or what I expect to receive in C.C.C.C interface is the following :
```
BYE <HERE SHOULD BE THE CALLER CONTACT URI> SIP/2.0
Via: SIP/2.0/UDP 80.10.231.173:5060;branch=z9hG4bKrdhsvc001omkvssqvfk0sd0185mt1.1
From: <sip:+33123456789@my-carrier-domain;transport=UDP;user=phone>;tag=SD69ao497-1472568650-1635329820043
To: <sip:+33987654321@my-own-domain;transport=UDP;user=phone>;tag=3ab10616
Call-ID: NjZjMDgyMGMxNzdkN2FhYmJlYzQyYjA5YWIzZThmZmI.
CSeq: 547381883 BYE
Max-Forwards: 64
Content-Length: 0
Route: <sip:D.D.D.D;r2=on;lr=on;ftag=3ab10616>
Route: <sip:C.C.C.C;r2=on;lr=on;ftag=3ab10616>
Route: <sip:B.B.B.B;r2=on;lr=on;ftag=3ab10616;dlg_id=426.26c2>
Route: <sip:A.A.A.A;r2=on;lr=on;ftag=3ab10616;dlg_id=426.26c2>
Contact: <sip:+33123456789@10.3.60.45;id=atpsh-617925e5-82a5-1>
```
I could work around this issue by doing the following :
1. When receiving the BYE/re-INVITE on interface D.D.D.D, I explode the Route headers, delete old route headers and create new ones in order from the result of explode
2. I update the ru with the contact uri which I stored in a htable when the initial INVITE was received
```
# Manage outgoing branches
branch_route[MANAGE_BRANCH] {
xdbg("new branch [$T_branch_idx] to $ru\n");
# TOPOS FIX
if (is_method("INVITE")) {
$sht(tpsindlg=>$ci) = $ci;
$sht(tpsindlg=>$ci:ft) = $ft;
$sht(tpsindlg=>$ci:ct) = $ct;
}
}
route[WITHINDLG] {
if (!has_totag()) return;
# Fix bad Route Headers caused by TOPOS module
if ($Ri == "D.D.D.D") {
$var(rh0) = $(hdr(Route)[0]{s.select,0,,});
$var(rh1) = $(hdr(Route)[0]{s.select,1,,});
$var(rh2) = $(hdr(Route)[1]{s.select,0,,});
$var(rh3) = $(hdr(Route)[1]{s.select,1,,});
remove_hf_re("^Route$");
append_hf("Route: $var(rh0)\r\n");
append_hf("Route: $var(rh1)\r\n");
append_hf("Route: $var(rh2)\r\n");
append_hf("Route: $var(rh3)\r\n");
}
# sequential request within a dialog should
# take the path determined by record-routing
if (loose_route()) {
# Fix R-URI caused by TOPOS module
if ($Ri == "D.D.D.D") {
if ($ci == $sht(tpsindlg=>$ci) && $tt == $sht(tpsindlg=>$ci:ft)) {
$ru = $(sht(tpsindlg=>$ci:ct){s.strip,1}{s.striptail,1});
if (is_method("BYE")) {
$sht(tpsindlg=>$ci) = $null;
$sht(tpsindlg=>$ci:ft) = $null;
$sht(tpsindlg=>$ci:ct) = $null;
}
}
}
route(RELAY);
exit;
}
if (is_method("ACK")) {
if ( t_check_trans() ) {
# no loose-route, but stateful ACK;
# must be an ACK after a 487
# or e.g. 404 from upstream server
route(RELAY);
exit;
} else {
# ACK without matching transaction ... ignore and discard
exit;
}
}
sl_send_reply("404","Not here");
exit;
}
```
Could you please tell if this is a normal behavior by TOPOS module or is it a bug?
Thank you.
--
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/2905
### Description
I have compiled Kamailio with google ASAN module and faced issue where the string PV with NULL value cannot be copied.
Using GDB I found this function call triggers error when Google ASAN is used, `value->s.s = NULL`, `value->s.len = 0`
```
memcpy(var->v.value.s.s, value->s.s, value->s.len);
```
[Link](https://github.com/kamailio/kamailio/blob/caccb13e29ee12166c8101efa0d…
This happens only when ASAN is used.
Without ASAN same function call with the same values does not trigger an error.
In my test case this function called from [`lost/functions.c:1285`](https://github.com/kamailio/kamailio/blob/caccb13e29ee12166c8101efa0d5ab2745876413/src/modules/lost/functions.c#L1285)
To compile with asan used extra flags
```
-fsanitize=address -fsanitize=undefined -fno-sanitize-recover=all -fsanitize=float-divide-by-zero -fsanitize=float-cast-overflow -fno-sanitize=null -fno-sanitize=alignment
```
### Troubleshooting
#### Log Messages
```
0(913407) INFO: {1 1 INVITE 1-455779(a)172.21.0.84} lost [functions.c:891]: lost_function(): ### LOST urn [urn:sip:911@3.236.25.254:5060]
0(913407) INFO: {1 1 INVITE 1-455779(a)172.21.0.84} lost [functions.c:983]: lost_function(): ### LOST loc [<112233445566(a)jim.com>]
0(913407) ERROR: {1 1 INVITE 1-455779(a)172.21.0.84} lost [utilities.c:336]: lost_get_content(): could not get XML node content
pv_svar.c:137:3: runtime error: null pointer passed as argument 2, which is declared to never be null
```
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
current master, test 375f86b69e11cf835ae919873d3cd56f32d589c8
* **Operating System**:
Centos 8
--
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/2913
Module: kamailio
Branch: master
Commit: 6857234c321faf33573e1a034ab666dc158eb549
URL: https://github.com/kamailio/kamailio/commit/6857234c321faf33573e1a034ab666d…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2021-11-04T17:15:49+01:00
core: reorder fields of struct _cfg_group for better alignment
---
Modified: src/core/cfg/cfg_struct.h
---
Diff: https://github.com/kamailio/kamailio/commit/6857234c321faf33573e1a034ab666d…
Patch: https://github.com/kamailio/kamailio/commit/6857234c321faf33573e1a034ab666d…
---
diff --git a/src/core/cfg/cfg_struct.h b/src/core/cfg/cfg_struct.h
index e03024e700..03f38f322d 100644
--- a/src/core/cfg/cfg_struct.h
+++ b/src/core/cfg/cfg_struct.h
@@ -76,7 +76,6 @@ enum { CFG_GROUP_UNKNOWN = 0, CFG_GROUP_DYNAMIC, CFG_GROUP_STATIC };
/*! \brief linked list of registered groups */
#pragma pack(push, 1)
typedef struct _cfg_group {
- int num; /*!< number of variables within the group */
cfg_mapping_t *mapping; /*!< describes the mapping betweeen
the cfg variable definition and the memory block */
char *vars; /*!< pointer to the memory block where the values
@@ -85,6 +84,7 @@ typedef struct _cfg_group {
cfg_add_var_t *add_var; /*!< Additional instances of the variables.
This linked list is used only before the config is
shmized. */
+ int num; /*!< number of variables within the group */
int size; /*!< size of the memory block that has to be
allocated to store the values */
int meta_offset; /*!< offset of the group within the
@@ -100,9 +100,9 @@ typedef struct _cfg_group {
to temporary set the handle in the main process and
restore it later to its original value. */
- unsigned char dynamic; /*!< indicates whether the variables within the group
- are dynamically allocated or not */
struct _cfg_group *next;
+ unsigned int dynamic; /*!< indicates whether the variables within the group
+ are dynamically allocated or not */
int name_len;
char name[1];
} cfg_group_t;
Add mqueue_name and mqueue_size to define queues.
Updated doc.
<!-- 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
<!-- Describe your changes in detail -->
Add 2 new mqueue module parameters to simplify config queue definition.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2825
-- Commit Summary --
* mqueue: add two new module parameters
-- File Changes --
M src/modules/mqueue/doc/mqueue_admin.xml (58)
M src/modules/mqueue/mqueue_mod.c (38)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2825.patchhttps://github.com/kamailio/kamailio/pull/2825.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/2825