I have been trying to replace the SDP connection IP with some other IP using module `mangler` (`Kamailio v5.7.0`). But It seem like its malfunctioning
```
if ($rs == 200) {
xlog("L_INFO", "200 $rm Detected");
sdp_mangle_ip("192.168.0.132/24","8.8.8.8");
}
```
and results I received are like this below
```
v=0 o=- 107808851201429815 2 IN IP4 192.168.0.132
s=- t=0 0
m=audio 24794 RTP/AVP 0 8 101
c=IN IP4 192.168.0.1328.8.8.8
a=mid:audio
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=ssrc:822878909 cname:0ZfUBhl8cMeHaeVl
a=nortpproxy:yes
```
I first ask the same question in mailing list `sr-users(a)lists.kamailio.org` but after waiting for some time (>24hrs) i cant see my question on on forum, that why I open a ticket here.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3554
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3554(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
I have some buggy devices that get upset by SRTP payloads in SDP that are marked inactive. As a hack, I was attempting to delete them when going to certain endpoints that are known to be problematic:
```
if (is_method("INVITE"))
sdp_remove_transport("RTP/SAVP");
```
### Troubleshooting
Per below, there is some garbage that looks like a port number inserted before `m=audio` that seems to have come from rtpproxy rewriting for NAT traversal. Removing the NAT traversal rewrite logic entirely fixes the problem, but also makes NAT traversal not happen. Changing the order of `sdp_remove_transport()` with respect to `rtpproxy_manage()` does not change anything.
#### Reproduction
This was seen with a Grandstream DP752 phone talking to SEMS, but applying the code snippet above and getting a packet trace will be enough. The original SDP had the RTP/SAVP transport first, followed by an RTP/AVP one. For the problem to occur, NAT SDP rewriting has to occur using rtpproxy.
#### Debugging Data
Here is the payload after sfp_remove_transport() removed the RTP/SAVP section:
```
v=0
o=15176190619 8000 8000 IN IP4 X.X.X.X
s=SIP Call
c=IN IP4 X.X.X.X
t=0 0
46108m=audio 55082 RTP/AVP 125 9 0 8 2 18 97 101
a=sendrecv
a=rtpmap:125 opus/48000/2
a=fmtp:125 maxplaybackrate=16000
a=ptime:20
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32-36,54
a=nortpproxy:yes
```
There is a garbage 46108 (I think what would have been the port number for SAVP data) at the beginning of the m=audio line. It seems that the rewrite by rtpproxy is still inserting this port number even though the transport in question has been removed.
#### Log Messages
None relevant.
#### SIP Traffic
(See above)
### Possible Solutions
None.
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
$ kamailio -v
version: kamailio 5.6.2 (x86_64/freebsd) 54a9c1
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, 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, select, kqueue.
id: 54a9c1
compiled on 10:44:33 Jul 20 2023 with cc FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
```
* **Operating System**:
FreeBSD 13.2
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3555
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3555(a)github.com>
Module: kamailio
Branch: master
Commit: b6979b503ffe65314526a8a2824f50b3f46b7a22
URL: https://github.com/kamailio/kamailio/commit/b6979b503ffe65314526a8a2824f50b…
Author: Kamailio Dev <kamailio.dev(a)kamailio.org>
Committer: The Root <root(a)kamailio.org>
Date: 2023-09-05T12:46:08+02:00
modules: readme files regenerated - tm ... [skip ci]
---
Modified: src/modules/tm/README
---
Diff: https://github.com/kamailio/kamailio/commit/b6979b503ffe65314526a8a2824f50b…
Patch: https://github.com/kamailio/kamailio/commit/b6979b503ffe65314526a8a2824f50b…
---
diff --git a/src/modules/tm/README b/src/modules/tm/README
index 0b44b81813c..19f4a9a3781 100644
--- a/src/modules/tm/README
+++ b/src/modules/tm/README
@@ -1864,11 +1864,12 @@ modparam("tm", "failover_reply_codes", "code=403;code=488;class=5")
4.1. t_relay([host, port])
- Relay a message statefully either to the destination indicated in the
- current URI (if called without any parameters) or to the specified host
- and port. In the later case (host and port specified) the protocol used
- is the same protocol on which the message was received. It creates a
- transaction.
+ Relay a SIP request statefully either to the destination indicated in
+ the current URI (if called without any parameters) or to the specified
+ host and port. In the later case (host and port specified) the protocol
+ used is the same protocol on which the message was received. It creates
+ the SIP transaction, if none was created before (e.g., with
+ t_newtran()).
t_relay() is the stateful version for forward() while t_relay(host,
port) is similar to forward(host, port).