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

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.

from rtpproxy.

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!

from rtpproxy.

Максим, вибачаюсь, 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.

from rtpproxy.

No problem. :)

from rtpproxy.