<!-- 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
tm module: In KEMI let's expose
t_relay_to_tcp
t_relay_to_udp
t_relay_to_tls
to force the transport.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2563
-- Commit Summary --
* tm: KEMI expose t_relay_to_xxx protocol functions
-- File Changes --
M src/modules/tm/tm.c (28)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2563.patchhttps://github.com/kamailio/kamailio/pull/2563.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/2563
### Description
Typical client device located behind NAT. If the customer use TLS or TCP transport then `nat_keepalive` cannot be used.
Details at [nat_traversal.c#L1389-L1391](https://github.com/kamailio/kamailio/blob/mast…
In this case, the TCP session may be expired on the NAT device, and future calls to the user phone not possible.
### Expected behavior
Send keep-alive messages for clients connected via TLS and TCP transport after `nat_keepalive` function call.
#### Actual observed behavior
Keep-alive messages do not send if phone connected via using TLS or TCP transport.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
[root@localhost kamailio]# kamailio -v
version: kamailio 5.5.0-dev3 (x86_64/linux) e9624b
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: e9624b
compiled on 04:01:18 Nov 10 2020 with gcc 8.3.1
```
* **Operating System**:
```
[root@localhost kamailio]# cat /etc/os-release
NAME="CentOS Linux"
VERSION="8 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="8"
PLATFORM_ID="platform:el8"
PRETTY_NAME="CentOS Linux 8 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:8"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-8"
CENTOS_MANTISBT_PROJECT_VERSION="8"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="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/2564
Hello,
I want to ask for your opinion on the best approach regarding the handling of locally generated 478 errors.
To give an example, like the ones generated from TM during t_relay() on an unresolvable destination.
Nov 25 17:40:13 kamailio[19345]: ERROR: {28607414 INVITE bba500ac-a9df-1239-6693-00505682c04d} tm [ut.h:286]: uri2dst2(): failed to resolve "invalid.skalatan.de" :unresolvable A or AAAA request (-7)
Nov 25 17:40:13 kamailio[19345]: ERROR: {28607414 INVITE bba500ac-a9df-1239-6693-00505682c04d} tm [t_fwd.c:1738]: t_forward_nonack(): failure to add branches
Nov 25 17:40:13 kamailio[19345]: CRITICAL: {28607414 INVITE bba500ac-a9df-1239-6693-00505682c04d} rtpengine [../../core/parser/../ip_addr.h:658]: ip_addr2sbuf(): unknown address family 0
These errors will not show up in onreply or failure_route. A long time ago this was discussed on the list [1], as some functionality were phased out out that support these scenarios.
Kamailio will try to generate a 478 with TM, this will obviously fail as well, and then generate a 478 with SL.
Question 1)
Is this intentional that the internally generated 478 is not showing up in the failure_route, like for for 408? This has been tested several times, but it is a complicated configuration.
Question 2)
Are there any other (better) ideas how to handle that besides using a "event_route[sl:local-response]" to catch this, e.g. to tear down otherwise stale rtpengine sessions etc..? As a side note, event_route[tm:local-response] seems not to work as well because of the tm failure.
Thanks,
Henning
[1] https://lists.kamailio.org/pipermail/sr-users/2011-June/069020.html
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com<https://gilawa.com/>