Do not use RTP packet with unknown payload to confirmed peer address

[kvrban]

Hi, Asterisk-16 send Generic NACK message on the involved RTP Port. rtpengine has no support yet, and write "RTP packet with unknown payload type 73 received" Ok, but it should not use this to Confirmed peer address, because then rtpengine send RTP to the RTCP Port.

[rfuchs]

Are you saying that Asterisk sends RTCP to the RTP port? Do you have an example of this? (pcap or similar)

[kvrban]

Yes, Asterisk send RTCP to the RTP port. I will prepare a pcap which show this behavior.
But i also want to discuss, if rtpengine should drop RTP with unknown payload to avoid this aftereffects?

[rfuchs]

Possibly, but not necessarily. It depends. That's why I'm curious to see the pcap.

[ShadoWalkeR31]

Hi. I get same trouble and save some logs and pcaps for issue

Screenshot maded on host with rtpengine (cant save pcap there via tcpdump - too many calls simultaneously), pcap from test asterisk where i process test call. I think main problem is that rtpeninge try to process RTCP message Real-time Transport Control Protocol (Generic RTP Feedback): NACK: 2 frames lost (on screenshot sngrep show it as h264 from asterisk converted to g711u somehow) and start dropping inbound h264 packets from endpoint (10.203.152.72) - after receive that packet - outbound counter freezes at 22400, but inboud still grow

Scheme:
video intercom(10.203.152.72:5060) -> kamailio with rtpengine (78.29.1.98:7777) -> asterisk (10.100.32.118:5060)

Rtpengine from sipwise repo https://deb.sipwise.com/spce/mr8.1.1/ version 8.1.1.2+0mr8.1.1.2
Asterisk from debian repos Asterisk 16.2.1dfsg-1+deb10u1, using chan_pjsip, dialplan simple - Ringing-Progress-Wait(180)
On both hosts Debian 10 buster.

I try to disable rtcp_mux, bundle on endpoint, set to max rtcpinterval in rtp.conf, but asterisk still send rtcp msg to rtp port for video and its start dropping at rtpengine.

rtpengine_video.zip
rtpengine.log

[ShadoWalkeR31]

PS: Its behaviour same even if asterisk call second endpoint and bridge call between them - video stopped in call, audio works.

[rfuchs]

Yeah, so this is caused by packet #16333, which is an RTCP packet to the RTP port. Unlike packet #10015, which is also RTCP but was correctly sent to the RTCP port. RTCP-MUX has not been negotiated, so I would say that this is a bug in Asterisk.

I think the correct workaround here is to detect RTCP on the RTP port even if RTCP-MUX is not enabled, and ignore the packet for validation purposes if RTCP is detected.

[rfuchs]

I've pushed commit 6d22af9 that should fix this. Are you able to test/confirm?

[ShadoWalkeR31]

I tested patch on non-production server where i can use rtpengine from scratches, add to file at sources version 8.1.1.1 (same as production version). Scheme same, only some ip addresses changes

At 10.100.32.118 i add to iptables rule -A INPUT -s 10.100.32.228 -p udp -m udp --dport 10000:20000 -m statistic --mode random --probability 0.03 -j DROP to emulate packet drops

W/o patch i get same behavior - RTCP message to RTP port drops RTP with video
With patch, RTP with video continues w/o any troubles. I noticed that same message for RTP with audio sended to correct RTCP - look like its realy bug somwhere in asterisk.

Add pcap and logs if it will be useful
2020_01_10_rtcp_at_rtp_cleaned.zip
2020_01_10_rtpengine.log