rtpproxy briefly sends RTP from out-of-range source port and with unrelated RTP header fields before starting to properly forward

[sindy39]

Hello,

first of all, please advise how to provide the correct traces - I have got a .pcap of the issue, which includes the UDP control exchange between opensips and rtpproxy, but I don't know what to do to collect debug information from the rtpproxy process itself as I am a newbie in rtpproxy&opensips area.

Besides, the issue only occurs (always) on a production virtual server (model name : AMD EPYC-Rome Processor) but I could never reproduce it on a test physical server (model name : Intel(R) Atom(TM) CPU C3558 @ 2.20GHz). Same (current from this git) version of rtpproxy compiled from source two days apart, and same versions of Debian, opensips, asterisk (updated the same day) run at both machines.

The signaling chain is CPE - opensips - transport #1 of asterisk - transport #2 of asterisk - 3PSE (3rd party SIP exchange). Direct media are permitted for both endpoints at the asterisk, so once the call is answered, asterisk re-invites the peers in order to make them send media directly to each other. So the media path during ringing is CPE - rtpproxy - asterisk - 3PSE, after connect it changes to just CPE - rtpproxy - 3PSE. rtpproxy does not run in bridge mode, I just specify "s" option for the CPE side and "ar" for the 3PSE side in opensips' rtpproxy_offer() and rtpproxy_answer().

Before connect, the calling CPE can hear the RTP (carrying alert audio) coming from the 3PSE in both environments; after the reINVITE, both parties can hear each other on the "working/test" server but only the calling party can hear the called one on the "non-working/production" one. The same CPE and 3PSE account are used for testing with both servers, one at a time.

I've tried to use nftables to prevent the incorrect RTP from being delivered to the 3rd party SIP exchange but it seems rtpproxy is hooked closer to the wire than nftables so I cannot even prove that the change of SSRC, sequence number, and/or timestamp is the root cause of the one-way audio (to my surprise, although the Asterisk registers to a normal CPE account at the 3PSE, the 3PSE does not auto-learn the wrong source port and keeps sending to the correct address:port indicated in Asterisk's SDP - maybe it only activates source learning if there is a private connection address in SDP).

[sindy39]

Sorry, jumped to conclusions too fast. Managed to start rtpproxy_debug with DBUG severity on another virtual machine (intentionally intel this time), and this time the test call shows that the wrong RTP has been there well before the rtpproxy even got engaged into that call branch.

[sobomax]

Hi, yes, those pcaps would be helpful. You should probably also run the rtpproxy with "-d dbug" option and send relevant logs showing activity around the call-id(s)/ports in question. You seems to have figured the last part by yourself, so if the problem persists please provide logs / pcaps to look at. Thanks!

[sindy39]

Максим, вибачаюсь, please close/reject/whatever this issue, as it is totally unrelated to rtpproxy. This was probably not clear enough from my update.

The strange RTP stream is generated by the Asterisk (PJSIP) and the difference between the "working" and "non-working" servers was that on "non-working" servers, the transport was linked to a public address (which is probably a very unusual setup) whereas on the "working" one it was linked to a private one.

[sobomax]

No problem. :)