When using uac_reg_request_to and the first trunk fails (as invalid credentials) try a second trunk, but there is something not cleaned or just doesn't get the new trunk auth params.
code example
```
failure_route[RETRY_OUTBOUND] {
if (t_check_status("401|407")) {
if(uac_reg_request_to("$rd", 0)) {
t_on_failure("RETRY_OUTBOUND");
xinfo("[RETRY_OUTBOUND] <$ci> | Doing authentication with $dd");
uac_auth();
t_relay();
exit;
}
}
if (next_routing()) {
$avp(out_trunk) = $rd;
# t_relay();
t_on_failure("RETRY_OUTBOUND");
t_relay();
exit;
}
}
```
running this code to those targets:
- TRUNK 10.3.3.11 (invalid user/pass)
- TRUNK 10.3.3.12 (correct user/pass)
produce this output in logs:
```
INFO: [RETRY_OUTBOUND] <xxxx1xxx@10.3.3.11:5060> | Doing authentication with 10.3.3.10
INFO: uac [auth.c:450]: uac_auth_mode(): no credential for realm "10.3.3.11"
INFO: [RETRY_OUTBOUND] <xxxx1yyyy@10.3.3.12:5060> | Doing authentication with 10.3.3.10
```
but if I simply remove the first trunk those credential works on the second trunk. is like some stuff (like the $dd) is not cleaned up / refreshed?
version:
```
version: kamailio 5.5.4 (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, 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 with gcc 8.3.0
```
running with drouting module to get next trunk
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3166
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3166(a)github.com>
Dear Gang
Possibly @oej could provide more in-depth information as he has witnessed this issue.
Usually the user of the from URI is the phone number displayed at the destination. There are situations where this phone number is translated.
As example. In Switzerland, the user is used to see numbers in a local format. National number starting with 0 and international numbers with 00 but on interconnection between telcos, e164 is used.
So basically when a call is sent to a customer '+41' is replaced by '0' and '+' is replaced by '00'.
Let's start with an example From: header:
`From: "Maurice Moss" <sip:+41991234567@example.com>;user=phone`
So shortly before the call is sent out to the location of the registered CPE, this is done:
```
if ($fU =~ "^\+41") {
$fU = "0" + $(fU{s.substr,3,0});
} else if ($fU = ~ "^\+") {
$fU = "00" + $(fU{s.substr,1,0});
}
```
What is sent to the CPE now looks like this:
`From: "Maurice Moss" <sip:0991234567@example.com>;user=phone`
Now we hit an error like 486 BUSY and the destination has call forwarding active to a mobile phone on another TSP. So we have to send the call out back the IC and numbers need to be translated back to e164.
We handle this in a failure route, which in turn could trigger a branch route.
So we revert the number back to e164:
`$fU = "+41" + $(fU{s.substr,1,0});`
Expected outcome:
`From: "Maurice Moss" <sip:+41991234567@example.com>;user=phone`
Observed outcome:
`From: "Maurice Moss" <sip:0991234567+41991234567@example.com>;user=phone`
So setting $fU more than once is appending to the user element of the From header URI.
This behavior has not been found in any documentation.
I have been working around most of the issues by making sure I change $fU (and $tU) at the latest possible time and only once. But in the case described above, I have not been able to come up with a work-around yet.
I also can't think of any benefit of the way those PV are handled or any harm that could be done, to handle them differently and make the last 'write' overwrite and previous value, instead of appending.
Thank you for looking into this.
-Benoît-
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3165
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3165(a)github.com>
### Description
when call detailed_ipv4_type function, pkg memory leak.
```c
detailed_ipv4_type($si,"$var(iptype)");
```
### Troubleshooting
#### Reproduction
just call detailed_ipv4_type function.
#### Debugging Data
```
ALERT: qm_sums: qm_sums(): count= 48161 size= 1789640 bytes from core: core/rvalue.c: rval_get_str(1293)
```
### Possible Solutions
ip address string not free in rval_get_str() function. [s->s=pkg_malloc(tmp.len+1/* 0 term */);](https://github.com/kamailio/kamailio/blob/1ddc27f199061025a6a43da3e8a1388fcaddfe19/src/core/rvalue.c#L1293)
need call pkg_free() free memory.
### Additional Information
test 3 version.
```
kamailio 5.5.4
kamailio 5.4.8
kamailio 5.3.9
```
* **Operating System**:
```
buster 10
ubuntu 20.04
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3159
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3159(a)github.com>
### Description
Topos still seems to break early-dialog UPDATEs in my configuration. This is on 5.6.0~rc0+bpo11.20220506004754.1 from 56-nightly which I believe includes c309122 and ceb688b. I haven't tested rc1 yet (there are no debs at this time) but there doesn't seem to be any topos-related commits since rc0 either.
### Troubleshooting
#### SIP Traffic
Attaching pcaps from a lab environment to demonstrate the problem. One with topos on (failure), one with off (success). There were no other configuration changes between these tests.
### Possible Solutions
Only turning topos off seems to resolve this for me.
### Additional Information
```
version: kamailio 5.6.0-rc0 (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, 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 with gcc 10.2.1
```
* **Operating System**:
```
Linux sbcprov0-stage-tis0-cn1 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64 GNU/Linux
```
[pcaps.tar.gz](https://github.com/kamailio/kamailio/files/8704222/pcaps.tar.…
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3112
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3112(a)github.com>