4 Sep
2023
4 Sep
'23
3:51 p.m.
<!--
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>