I have tried with "Use public STUN servers" checked and unchecked. No luck. Same with "Ignore VoIP support check".

Thank you for reporting this issue. It looks like it doesn't like the URL for STUN server that is created from the details provided by XMPP server to which you are connecting.

Do you use your own XMPP server? or some public XMPP server? I'm asking as I having details that are provided from XMPP server about TURN/STUN server would be helpful to find the cause of this issue.

My XMPP server is a Snikket server hosted by jmp.chat. I couldn't say exactly when calls stopped working, but I know for a fact calls used to work on my BeagleIM on my jmp.chat Snikket server until as recently as last month.

Edit: Actually, I think calls were working as recently as October 5th, based on my chatlogs. — I've asked their main group chat if there's any info on TURN/STUN setup.

FWIW:

[2024-10-19 08:37:09] <singpolyma>: someguy, MattJ: Hmm. Looks like not a problem with the server but with the uri. I vaguely recall that xmpp servers return stun URIs that libwebrtc considers invalid. So beagle could fix it their side but maybe these URIs are actually invalid?

Actually...calls "work" (just can't close it without Command+Q and can't see any info) on BeagleIM 5.3.6-b179:

But they don't work at all on BeagleIM 5.3.6-b180, so this seems to be a regression on the Beagle side (or one of its dependencies)?

There wasn't even all that many changes, but I don't know what might've broken it: https://github.com/tigase/beagle-im/compare/5.3.6-b179...5.3.6-b180

None of the changes listed here points to anything that could cause VoIP issues or would change STUN/TURN uri generation. As for the issue with version 5.3.6-b179, we were aware of those issues and worked on resolving those in b180.

I think that during fixing those issues we upgraded WebRTC version to M122 that is now used in Beagle - that could explain why it started to reject STUN/TURN URI in b180 (previously older version was used).

I'll try to look into this issue soon and hopefully we will be able to fix it, but I cannot say for sure as for us b180 works just fine (even with TURN/STUN server configuration provided by XMPP server).

Some additional details from public chatlogs:

[2024-10-19 09:35:38] <us>: someguy: not that it helps much, but: https://chromium.googlesource.com/external/webrtc/+/master/pc/ice_server_parsing.cc#223

// stun with ?transport (or any ?) is not valid.

[2024-10-19 09:36:58] <us>: see also some (recent?) w3c recommended changes in this area: https://github.com/w3c/webrtc-pc/issues/2660

This is most likely it:

I think that during fixing those issues we upgraded WebRTC version to M122 that is now used in Beagle - that could explain why it started to reject STUN/TURN URI in b180 (previously older version was used).

Unfortunately, I don't know a thing about Swift (I can barely muddle through Python and Go at extreme mental anguish), so I wouldn't be able to submit any patches, but I'm more than happy to test any changes. :-)

I've narrowed it down to the exact line in WebRTC that is now reporting an error, that has following comment around this change:

// stun with ?transport (or any ?) is not valid.

Most likely getting rid of transport being set from XEP-0215 (returned by the server) should resolve this issue for you.

Beagle IM and Siskin IM are adding ?transport= to the STUN or TURN URI, if XMPP server returns transport attribute in the <service/> element returned as part of XEP-0215 response.

Seems like M121 is the final one to allow ?transport (any ?), though the deprecation started in M110: https://groups.google.com/g/discuss-webrtc/c/L0qDWipd7VE/m/KKfmlY08AgAJ

I understand if there's no interest, but I'm more than happy to test a build with M121.

I think jmp.chat staff will be doing some testing later as well:

[2024-10-19 10:41:36] <ossguy>: someguy: I mean you could run your own to test 😊 but yes, it's on our list to test when staff or others are available

Making a build with M121 is not an option. Simple build of WebRTC takes a lot of time and there are no ready to use builds for iOS or macOS.

Changing transport field value from XEP-0215 (to not be included) should be simple and shouldn't cause any issues as far as I'm aware (at least it is in Tigase XMPP Server).

As for a possible workaround in Beagle IM, I could make a change to "ignore" transport field value when generating STUN URI, however I'm not convinced that I should as it is passed from the XMPP server, so it seems that sending it for STUN service is a possible configuration issue.

I'm open to persuasion, but I think that it is still useful to inform XMPP clients about the available transports for STUN, right?

There is some information about why ?transport is not relevant for STUN here: https://marc.petit-huguenin.org/2012/09/on-the-design-of-the-stun-and-turn-uri-formats/

My understanding from skimming this is that which STUN transport to use is determined by need, but TURN is a bit more flexible - which is why it's possible to signal preferred transport in TURN URIs. However, for the sake of interoperability, it seems like it's still useful for an XMPP client to know if the XMPP server does (or does not) support a particular STUN transport. If WebRTC always uses UDP, then the client can check this and filter out entries that aren't compatible.

If I'm correct (I'm pretty sure I'm as I worked with STUN and even wrote STUN component for Tigase a while back), STUN is UDP-only (as this is a shortcut from Simple Traversal of UDP (User Datagram Protocol) through NATs (Network Address Translators)). Due to that there is no need to inform STUN about usage of UDP as a transport as only UDP can be used.

Due to that XMPP client do not need to know what transport should be used and sending transport as UDP by the XMPP server is overkill and unnecessary.

On the other hand, WebRTC could accept UDP as a transport without creating compatibility issues.

Resorting to adding workaround in the XMPP clients is not the best solution in my opinion, while transport field sent as part of the XEP-0215 is configurable on the server side, and setting it to null to stop sending transport attribute isn't rather an issue.

If I'm correct (I'm pretty sure I'm as I worked with STUN and even wrote STUN component for Tigase a while back), STUN is UDP-only (as this is a shortcut from Simple Traversal of UDP (User Datagram Protocol) through NATs (Network Address Translators)). Due to that there is no need to inform STUN about usage of UDP as a transport as only UDP can be used.

I don't think it's common (and perhaps not at all in webrtc) but I believe STUN can indeed be used over TCP (and/or TCP+TLS):

When reliability is mandatory, the Transmission Control Protocol (TCP) may be used, but induces extra networking overhead. In security-sensitive applications, STUN may be transported and encrypted by Transport Layer Security (TLS). [...] The standard listening port number for a STUN server is 3478 for UDP and TCP, and 5349 for TLS. -- https://en.wikipedia.org/wiki/STUN#Design