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 -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)

FreeBSD 13.2


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <kamailio/kamailio/issues/3555@github.com>