Has anyone actually got Jami to work reliably?

Generic topics
1

I’ve been trying Jami off and on for years! Now and again it will work for a while but then messages stop going through or being received.

I’ve tried on various devices/platforms and various Jami settings (STUN, find local network on/off etc), local WiFi networks and mobile networks.

Sometimes changing settings or toggling account on/off seems to bring it back to life for a while but then it seems to go to sleep again, accounts don’t sync etc.

So anyway, has anyone got it working reliably over time? If so, what settings, platform etc.

I want it to work!!

1 Like
2

Are you using MacOS?

3

Maybe also related:

5

Yes.

Works brilliantly.

:+1:

2 Likes
7

It’s Ubuntu 22.04 :+1:

1 Like
8

I have GNU+Linux Mint Cinnamon on an older HP Laptop. Tried it with some friends.

Takes a lot of power from the computer to encrypt, but it was a very nice feeling anyway and worked 95%. Sound was flawless.

However, I can not run OBS Studio and broadcast Jami with my old Laptop. So for this I prefer another open free P2P video chat, at the moment, without login to Google, Facebook or Github (Microsoft). (Not open, not free and probably surveilled).

Good luck in making your real friends as open and free as Jami! “Free as in Freedom”!

1 Like
9

I agree with the OP. I never had any luck. It has a non-intuitive interface. Maybe that’s why it is so hard to configure.

1 Like
10

Hi JamiMan7!
I initially had a similar experience, until I realized I had to use the “X” to get out from the settings. This is “smartphone logic”. Try, and try again! Eventually you will get it!

11

Following up on OP’s post, I too WANT to get Jami working! It’s an admirable product. I am a long time Tox user. Also a great tool but is buggy and is not being actively supported. Jami has a paid, enterprise version so I figured Jami was stable and well supported. But like OP, I am having great difficulty doing even simple things like sending messages to someone.

Swarm is a great idea but I can’t even get Jami to work reliably P2P to an account that has a solo client. I am testing on Ubuntu 22.04 LTS clients mostly but also see issues with IOS and Android.

Biggest fail is just sending a message to a user. I have tried various connection combinations thinking I’m hitting a use error… I send a message. The user accepts the conversation. The swarm goes into a “waiting until user connects to sync convo” death spiral that is never satisfied.

I’ve had some cases where it works as it should but I have a test bed where it consistently fails. As OP says, everything is enabled, no VPN in the picture. snap jami version 293. Tried to download possible newer versions from the jami site and got a forbidden msg.

I (and I’m guessing many others) could REALLY use some help getting this working reliably. Thanks in advance!

1 Like
12

Yes, the GUI is not at all intuitive and does take some getting used to. Although at this point I am inclined to think that my (and OP’s) problem is not user error. It would be great if Jami had a contact list of “friends” who can be messaged like every other IM app on the planet. This “waiting to sync” fiasco seems to be caused by the implementation of the swarm scheme. IMHO, the developers should get basic P2P working solidly before adding support for multiple device support of the same user.

13

The GUI must be intuitive. Usually a programmer will create the GUI so as to see how things are laid out and if they make sense, and only then filling out the programming to make it come alive. It is almost as if the programmers created the GUI as an afterthought.

Then the next step should be the mechanisms to get the programming to connect with the network necessities. If the programmers first go after the way they want to make connections work, they risk reinventing the wheel and/or going off on a tangent. Both are counter-productive.

14

Are you able to provide version for both side and logs?

15

Jami 20231128.0 v293 from snap store running on Ubuntu 22.04 LTS desktop (both clients). I see nothing interesting in the logs. I see no way to capture logging from “waiting for sync” connections.

[1702917637.156|20731|manager.cpp :957 ] ############## START MONITORING ##############
[1702917637.156|20731|manager.cpp :958 ] Using PJSIP version 2.13.1 for x86_64-pc-linux-gnu
[1702917637.156|20731|manager.cpp :959 ] Using GnuTLS version 3.6.13
[1702917637.156|20731|manager.cpp :960 ] Using OpenDHT version 3.0.0
[1702917637.156|20731|manager.cpp :967 ] Opened files: 423
[1702917637.156|20731|routing_table.cpp :200 ] BUCKET Number: 1
[1702917637.156|20731|routing_table.cpp :207 ] Mobile Nodes
[1702917637.156|20731|routing_table.cpp :214 ] Known Nodes
[1702917637.156|20731|routing_table.cpp :220 ] Connecting_nodes
[1702917637.156|20731|routing_table.cpp :200 ] BUCKET Number: 1
[1702917637.156|20731|routing_table.cpp :207 ] Mobile Nodes
[1702917637.156|20731|routing_table.cpp :214 ] Known Nodes
[1702917637.156|20731|routing_table.cpp :220 ] Connecting_nodes
[1702917637.156|20731|routing_table.cpp :200 ] BUCKET Number: 1
[1702917637.156|20731|routing_table.cpp :207 ] Mobile Nodes
[1702917637.156|20731|routing_table.cpp :214 ] Known Nodes
[1702917637.156|20731|routing_table.cpp :220 ] Connecting_nodes
[1702917637.156|20731|routing_table.cpp :200 ] BUCKET Number: 1
[1702917637.156|20731|routing_table.cpp :207 ] Mobile Nodes
[1702917637.156|20731|routing_table.cpp :214 ] Known Nodes
[1702917637.157|20731|routing_table.cpp :220 ] Connecting_nodes
[1702917637.157|20731|routing_table.cpp :200 ] BUCKET Number: 1
[1702917637.157|20731|routing_table.cpp :207 ] Mobile Nodes
[1702917637.157|20731|routing_table.cpp :214 ] Known Nodes
[1702917637.157|20731|routing_table.cpp :220 ] Connecting_nodes
[1702917637.157|20731] ConnectionManager current status:
[1702917637.157|20731] ConnectionManager end status.
[1702917637.157|20731|manager.cpp :976 ] ############## END MONITORING ##############

IOS to Ububntu and Android to Ubuntu (initiated from either direction) seem to work although testing has been limited. Problem seems more Ubuntu to Ubuntu clients centric. I do, however have two Ubuntu clients reliably communicating with each other.

17

Actually the interesting time will be whenever the peer becomes online. It will try to sync at this point (when the presence change is detected).

1 Like
18

Would that what you say was true. I have quit and restarted the Jami sessions for users “needing to sync” many times, rebooted the desktops, bounced the jami processes… NOTHING causes a presence change to be sent to the client waiting for the sync to happen.

This, sir, is the major problem that I and the OP (as well as others) are reporting. I’ve seen threads on this issue that are a year or more old. With all due respect, the dev team needs to take a serious look at this instead of just dismissing these reports.

As I said the swarm initiative sounds like a good idea on paper. But for Jami to gain widespread acceptance in a production environment, being able to message someone reliably is a core requirement. This, sadly, is NOT the case today. At least not Ubuntu to Ubuntu clients.

19

That’s why I asked for the logs both sides while it should sync, without reproducible scenario in our end, information like “X is not working” is pretty useless to debug as we can’t provide any useful information. There should not be any special settings, default should works, if it’s not, finding the original cause is the objective, not randomly playing with buttons until it works. So, the idea is to dig and retrieve enough information to understand what can be wrong.

being able to message someone reliably is a core requirement

I agree with this and it’s always the main priority.

For now, what I know is it’s between 2 ubuntu 22.04/snap 20231128.0 v293

20

I agree completely and no disrespect was intended. Sometimes Jami works as expected, sometimes not. It’s been difficult to create a test bed where it fails consistently. For the example I posted, here is the log on the client that is failing to sync:

[1702929759.840|5127|manager.cpp :957 ] ############## START MONITORING ##############
[1702929759.840|5127|manager.cpp :958 ] Using PJSIP version 2.13.1 for x86_64-pc-linux-gnu
[1702929759.840|5127|manager.cpp :959 ] Using GnuTLS version 3.6.13
[1702929759.840|5127|manager.cpp :960 ] Using OpenDHT version 3.0.0
[1702929759.841|5127|manager.cpp :967 ] Opened files: 92
[1702929759.841|5127|routing_table.cpp :200 ] BUCKET Number: 1
[1702929759.841|5127|routing_table.cpp :207 ] Mobile Nodes
[1702929759.841|5127|routing_table.cpp :214 ] Known Nodes
[1702929759.841|5127|routing_table.cpp :220 ] Connecting_nodes
[1702929759.841|5127|routing_table.cpp :200 ] BUCKET Number: 1
[1702929759.841|5127|routing_table.cpp :207 ] Mobile Nodes
[1702929759.841|5127|routing_table.cpp :214 ] Known Nodes
[1702929759.841|5127|routing_table.cpp :220 ] Connecting_nodes
[1702929759.841|5127] ConnectionManager current status:
[1702929759.841|5127] ConnectionManager end status.
[1702929759.841|5127|manager.cpp :976 ] ############## END MONITORING ##############
[1702929760.541|5379] [TLS] handshake failed: The operation timed out
[1702929760.542|5379] [device 686186c3354eb802a0b307ba3427aeba051ccd589e849c89f294d5bd20575abd] TLS connection failure - Initied by connectDevice. channel: git://686186c3354eb802a0b307ba3427aeba051ccd589e849c89f294d5bd20575abd/b8beaa63eb35771a4ff9c1c46d36700247a233a3 - vid: 3189644880432439
[1702929778.310|5298] Mapping status [TCP] - overall 5: 5 open (4 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702929778.310|5298] Mapping status [UDP] - overall 9: 9 open (8 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702929808.350|5298] Mapping status [TCP] - overall 5: 5 open (4 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702929808.370|5298] Mapping status [UDP] - overall 9: 9 open (8 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702929838.350|5298] Mapping status [TCP] - overall 5: 5 open (4 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702929838.350|5298] Mapping status [UDP] - overall 9: 9 open (8 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702929868.350|5298] Mapping status [TCP] - overall 5: 5 open (4 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702929868.360|5298] Mapping status [UDP] - overall 9: 9 open (8 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702929898.360|5298] Mapping status [TCP] - overall 5: 5 open (4 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702929898.360|5298] Mapping status [UDP] - overall 9: 9 open (8 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702929928.360|5298] Mapping status [TCP] - overall 5: 5 open (4 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702929928.360|5298] Mapping status [UDP] - overall 9: 9 open (8 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702929958.360|5298] Mapping status [TCP] - overall 5: 5 open (4 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702929958.360|5298] Mapping status [UDP] - overall 9: 9 open (8 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702929988.360|5298] Mapping status [TCP] - overall 5: 5 open (4 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702929988.360|5298] Mapping status [UDP] - overall 9: 9 open (8 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702930018.360|5298] Mapping status [TCP] - overall 5: 5 open (4 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702930018.360|5298] Mapping status [UDP] - overall 9: 9 open (8 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702930048.360|5298] Mapping status [TCP] - overall 5: 5 open (4 ready + 1 in use), 0 pending, 0 in-progress, 0 failed
[1702930048.360|5298] Mapping status [UDP] - overall 9: 9 open (8 ready + 1 in use), 0 pending, 0 in-progress, 0 failed

21

I don’t take it personally and I don’t think there was any disrespect.

Taking time to report an issue is still appreciated. Just that we have to sort the report afterwards. And if we can’t reproduce/can’t dig, we generally ask for more information (and if no answer, close the ticket).

For the example I posted, here is the log on the client that is failing to sync:

The log starts too late (probably just starting jami -d in a terminal will be useful). But for what I see: [TLS] handshake failed: The operation timed out Seems a handshake is started in this case (so at least a peer is detected and a request is made to this device). The timeout can occurs for a lot of reason, and the other peer will show more information in this case (at least if a request is received, handled or a TLS error occured)

22

There are no new entries in the log for the other client since I posted that log (above). There is no connection listed to the pillows user in the troubleshooting window.

Having difficulty copying log text from one machine to another. I see no mechanism for attaching a log file to this forum.

jami -d is very verbose and likely very helpful. I’ll post a snippet (communications between the two clients in question from the terminal):

[1702932077.869|6430] [TLS] Start client session
[1702932077.883|6430] [TLS] User identity loaded
[1702932077.883|6430] [TLS] handshake
[1702932077.897|6430|manager.cpp :273 ] [1]GnuTLS: Discarded message[0] due to invalid decryption
[1702932077.897|6430] [TLS] handshake failed: Decryption has failed.
[1702932077.898|6430] [device b2aa562b513c4550e87c4009cfd55e786ce32ee4508d8228f2d643e41d0941c1] TLS connection failure - Initied by DHT request. channel: - vid: 2304632640504633
[1702932078.829|6395] [device bd128c2ff227d34e34d0b7cc92ddd34141692f3a5b7ebc56be6c61ecedbaf873] Answer to connection request: put encrypted ok
[1702932079.100|6395] [device b2aa562b513c4550e87c4009cfd55e786ce32ee4508d8228f2d643e41d0941c1] Answer to connection request: put encrypted ok
[1702932089.843|6395|jamiaccount.cpp :3194] [Account 6c4ae11351c130a4] [message 1812154021472572] Put encrypted ok

[1702932971.212|6473] [TLS] Start server session
[1702932971.222|6471|manager.cpp :273 ] [1]GnuTLS: Discarded message[0] due to invalid decryption
[1702932971.222|6471] [TLS] handshake failed: Decryption has failed.
[1702932971.222|6471] [device b2aa562b513c4550e87c4009cfd55e786ce32ee4508d8228f2d643e41d0941c1] TLS connection failure - Initied by DHT request. channel: - vid: 4529209470158177
[1702932971.228|6473] [TLS] User identity loaded
[1702932971.228|6473] [TLS] handshake

[1702932971.209|6468] [ice:0x7f0a184eb200] TCP connection pairs ([comp id] local [type] ↔ remote [type]):
[2] 192.168.0.100:12962 [host] ↔ 192.168.0.21:35854 [prflx]

[1702932971.211|6380] [device bd128c2ff227d34e34d0b7cc92ddd34141692f3a5b7ebc56be6c61ecedbaf873] Start TLS session - Initied by connectDevice(). Launched by channel: sip - vid: 41196222604121

23

This seems like it may be the smoking gun? Killed everything jami on both desktops. The desktop waiting for the other to sync issued these log entries after both were restarted. Hope this helps. I’d love to know what’s keeping Jami fro working but only in select configurations. Both of these desktops are able to talk to others just fine. Seems to have something to do with invalid encryption. Ring any bells? A bug in the snap version of Jami I’m using?

[1703017907.900|23998] [ice:0x7fccac08d7a0] TCP connection pairs ([comp id] local [type] ↔ remote [type]):
[2] 192.168.0.15:43356 [prflx] ↔ 192.168.0.100:44115 [host]

[1703017907.900|23854] [device 7428db054608e89adefa1f2f8ea829df6348c6bae8098c39320ff004602ef5f9] Start TLS session - Initied by connectDevice(). Launched by channel: git://7428db054608e89adefa1f2f8ea829df6348c6bae8098c39320ff004602ef5f9/eab24ee4e22187ff3310664b611f112f7e5f8de3 - vid: 5538213472325577
[1703017907.901|24004] [TLS] Start server session
[1703017907.909|24004] [TLS] User identity loaded
[1703017907.909|24004] [TLS] handshake
[1703017947.909|24004] [TLS] handshake failed: The operation timed out
[1703017947.909|24004] [device 7428db054608e89adefa1f2f8ea829df6348c6bae8098c39320ff004602ef5f9] TLS connection failure - Initied by connectDevice. channel: git://7428db054608e89adefa1f2f8ea829df6348c6bae8098c39320ff004602ef5f9/eab24ee4e22187ff3310664b611f112f7e5f8de3 - vid: 5538213472325577