<!-- 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: &lt;kamailio/kamailio/issues/3555(a)github.com&gt;