UI for call/file share connection path control

It would be great to have a more precise control over the path peers connect while making a call or sharing a file.

A few use cases and ideas:

  1. I was really surprised, that two peers were able to find out that they are on the same LAN while negotiating for a call. But to understand that I needed to actually run Wireshark. It would be great to have something like an icon in call UI indicating, whether the connection is made through TURN, STUN, LAN, or whether the other side have an accessible IP on the clearnet, or maybe its you who have an accessible from outside IP address, or both. It would also be great to actually see the address of the other side and of the TURN/STUN server in UI. It may be usable for troubleshooting, and not showing it to user just gives a fake sense of full privacy.

  2. It would be great to be able to manually allow/disallow your Jami application to connect through certain connection paths. Different people may have different security models.

  3. Currently, UI allows only one TURN server in its configuration. It would be great to be able to add several of them. For example, a user may want to self-host a TURN server for personal usage, so that his/her communication would not be disrupted in moments when there is too many connections through the default one. And his/her ISP provides perfectly stable connection… until a tree falls and breaks an optical fiber. So, it would be great to have the default TURN server persist in the application’s config as a fallback.

  4. Currently, there is only one way of authentication on a TURN server - with user/password. Maybe, there are other ways of authentication implemented in existing TURN server software? Maybe, keypair-based, or one-time-password, or something. Because, there is no way that someone guesses a password, when there is no password. :wink:

  5. We always need to make a trade-off be between reliability and privacy/security. It may be useful for those who needs a paranoid level of security to be able to use the TOR network instead of a TURN server so that their IP remains hidden. Don’t know if this really makes any sense, but it is worth a discussion.

And a side note. According to this page, a connection is made before a recipient accepts a call. So, in STUN mode the recipient’s IP is revealed even if he/she does not accept a call. It would be great to have an explanation of this caveat somewhere near the “Allow incoming calls from unknown contacts” option in settings.

@mdmisch and thank you for the feedback

Indeed getting more these information easily would be useful for us, for understanding scenarios and in logs. We want to improve this, but it’s not a priority right now. Moreover, daemon logs already give a lot of informations and already logs all the links and give already plenty of informations. In the UI, 99.9% of the users don’t care about this.

  1. All is already in the log instead of wireshark. For example you will see:

1604947230.019|60750|ice_transport.cpp :607 ] [ice:0x7fb47c156de0] TCP connection pairs ([comp id] local [type] <-> remote [type]):
[1] [host] <-> [prflx]

And all connections in Jami are in the logs (run dring with “-cd”)

  1. yeah this can be improved, but quite not standard. Actually you can enabled TURN/STUN/UPnP for your side in the settings, the other part must do the same if it wants to force local. We follow RFCs on ICE to perform a lot of connections

  2. Imho it’s not really wanted. This will rapidly increase the number of paths to check and pj will get too many candidates errors quickly. But adding multiple turn servers is possible, but not at all a priority

  3. Yeah there is some others (such as OAuth), feel free to read the RFCs here: https://github.com/coturn/coturn. Again can be cool and any PR about this will be appreciated

  4. Yeah the main problem for TOR it’s that it doesn’t support UDP. And the DHT + medias are using UDP connections. However, Jami works with orbot if you don’t care about medias, only text + file transfer & if DHT proxy is enabled.

For the side note, this page is in progress: https://git.jami.net/savoirfairelinux/ring-project/wikis/technical/2.4.%20Let’s%20do%20a%20call
If “Allow incoming calls from unknown contacts” is unchecked, no ICE messages will be transmitted. So the connection should not exists

1 Like