chatmail
feat: Use turn.delta.chat as fallback TURN server (#7382)
Note that if the server doesn't support IMAP METADATA, the fallback TURN server isn't used. I didn't get why the code is written this way, i.e. create_fallback_ice_servers() is only called if the server supports METADATA, do we want to change this?
Looks working, tested with a nine profile and non-chatmail too. For testing with the release DC Desktop apply 8f6ce74 also, otherwise the "Call" button isn't even shown.
Close #7382
Note that if the server doesn't support IMAP METADATA, the fallback TURN server isn't used. I didn't get why the code is written this way, i.e.
create_fallback_ice_servers()is only called if the server supports METADATA, do we want to change this?
i agree, this looks wrong.
IMAP METADATA is not supported by all server (iirc, e.g. it is not enabled by default dovecot installs) - and i do not see a good reason why core should not pass default TURN server to UI in that case. esp. as this will result in bad UX and bad debuggability, as we still cannot know a TURN server is returned in all cases.
the only reason that come to mind is that the code gets too complexity, and if IMAP METADATA is supported by >99% of servers - but i doubt both, cc @link2xt will have more insights
do we want to change this?
It's a bug, if IMAP METADATA is not supported we should use the fallback server as well.
It's a bug, if IMAP METADATA is not supported we should use the fallback server as well.
Pushed a fix for this as well.
this pr includes unrelated changes, namely it seems to revert #7285
maybe a mistake that happened during rebase? or sth. left over from development?
Removed the reverting commit. I added it initially because w/o it one can't test this PR in the release version of DC Desktop, the "Call" button isn't even shown.
Finally this looks working for me, i just didn't know how to test it the right way. It's not necessary to force using TURN via the WebRTC API, even having devices in the same network just do smth like:
iptables -A INPUT -s 192.168.1.x -j DROP
iptables -A OUTPUT -d 192.168.1.x -j DROP
ip6tables -A INPUT -s 2800:a4:673:bd00:3e9e:5639:93df:xxxx -j DROP
ip6tables -A OUTPUT -d 2800:a4:673:bd00:3e9e:5639:93df:xxxx -j DROP
Then after an unsuccessful direct connection the offering side will use TURN and the accepting side -- STUN:
Selected candidate pair: local: srflx (STUN) 190.134.202.123 => remote: relay (TURN) 46.224.39.230.
Better if somebody else tests this too, but it's ready for review.