On 03/03/2022 09.41, [EXT] Rhys Hanrahan wrote:

OK, I know this might be better served on the rtpengine list but just wanted to quickly post a debug log incase you get a chance to take a look overnight (my night hehe). https://pastebin.com/iHRQSTuD

First off, this does show the "offer" being given to rtpengine multiple times (with slightly different options) which does suggest that there are multiple branches, but this alone is not why you see what you see. The telltale log line is this:

MarĀ  4 01:32:39 sbc5-syd-01 rtpengine[12534]: [1646317959.098841] DEBUG: [f9d974b1ef245c3384400fa47beee1fb]: enabling passthrough mode
At this point rtpengine disables all data manipulation (including SRTP handling) and reverts to dumb UDP forwarding mode. It does this because in the last "offer" given there was no `ICE=` option given, and the incoming "offer" had ICE attributes present. I'm guessing this is a slightly older version of rtpengine (because newer versions have a saner default behaviour for this case) but in this case the combination of incoming ICE offer and lack of `ICE=` option puts rtpengine into "optional ICE relay" mode, which means it cannot be sure that media will pass through it, requiring it to fallback to passthrough mode.

Long explanation short: either upgrade, or make sure to always add an `ICE=` option to your offer flags (either ICE=remove or ICE=force).

Branch handling should also be addressed but is a separate topic. If you're doing the branching yourself, usually adding `via-branch=next` to the offer flags and `via-branch=1` to the answer flags does the trick.

Cheers