3 Mar
2022
3 Mar
'22
8:01 p.m.
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