Open xenithorb opened 9 years ago
I have never used this, so I don't really know. But from what others have reported, calling works fine, but receiving does not. See the comments in here: https://github.com/JavaJens/TextSecure/issues/39
However, I think the registration is still disabled.
@f41c0r I think we can enable the registration to Redphone. What do you say? From a quick test this allows calling people, but, of course, being called doesn't work. The caller that tries to call a websocket phone gets a message "Not registered user" or similar.
I'm fine with it, as long as its clear to everyone that its buggy, maybe add a note in the readme about it and add it to the popup code you just merged?
being called doesn't work.
Is this a problem of upstream, i.e. is there no websocket API for the phone-stuff? Or is it a problem in the forked client?
If I can help through testing, please let me know!
Thanks!
@h-2 Well, sorta. The source code for the (unified) server is not available. I think they are running two separate servers in parallel, so the phone stuff is handled by the original RedPhone server for which there never was open source.
I asked on the mailinglist regarding websocket support for calls, but never got a reply. I might open a ticket against the server source, but am not sure yet on how to make it an issue and not a discussion :wink:
so the phone stuff is handled by the original RedPhone server for which there never was open source.
really? :worried:
Do you know if they ever planned on releasing it?
I might open a ticket against the server source, but am not sure yet on how to make it an issue and not a discussion :wink:
Yeah, I understand. Thanks for not giving up :+1:
Do we have any documentation whatsoever on the redphone protocol? Is there a chance its just vanilla XMPP + ZRTP like jitsi can do?
I saw your post on the mailing list javajens, I hope they decide to release source... :S
@f41c0r It's standard ZRTP, but they use their own simple signaling protocol, not XMPP or SIP. But with key continuity check disabled after switch from RedPhone to Signal, there is much greater chance of MITM then in other ZRTP-based phone apps :-(
Can confirm that with the self-compiled code from websocket-reborn branch, getting voice called (likely from normal signal) and voice calling (likely to normal signal) does not work. The first times out after a while, the latter says "Login failed" immediately.
+1 for documenting known-working and known-not-working stuff.
Also getting an immediate "Login Failed" upon WebSocket --> GCM.
Still an issue with 3.8.1-websocket for me (and I presume, everyone else).
Anyone working on getting this fixed?
When calling --> "LOGIN FAILED!" almost immediately. Others calling --> says my number is not registered for secure voice.
@sarevok-anchev First somebody has to convince moxie0 to open-source the RedPhone server...
@mimi89999: Could you clarify? RedPhone/Signal are open source, couldn't whatever magic they're doing be replicated in LibreSignal?
What exactly is failing here?
And how to best move forward?
RedPhone/Signal are open source, couldn't whatever magic they're doing be replicated in LibreSignal?
They use GCM (Google Cloud Messaging). If you don't have gapps installed on your phone, you can't use GCM... (and probably you don't want to install gapps :-) )
Look at: https://github.com/JavaJens/TextSecure/issues/54#issuecomment-160419089
I see. Indeed, I don't want to install gapps :)
So, essentially, we'd need to get moxie0 onboard with the effort in order to have working calls from/to LibreSignal?
I can confirm that the normal (not -websockets) builds of LibreSignal work with calls if you use microG on your (rooted, and if it isn't OmniROM or built yourself with relevant signature-spoofing patches, with an xposed module) GApps-free Android device. @mimi89999
@aphirst any docs about the whole procedure?
@ThomasWaldmann Install instructions for microG here - it's all also on github and FOSS in case you're worried about it being some dodgy XDA homebrew. It mentions either the patch to apply to an Android source tree or the Xposed module to install.
The only other real longterm option would be to have (Libre?)Signal use something akin to onepf instead of committing to a specific Cloud service. But I think that needs a lot more momentum still. Wrestling control out of Google's hands should be a high priority, especially when the "workarounds" either involve installing proprietary software, or making invasive modifications to your ROMs in light of which many ROM Developers decide to no longer support you.
If Libresignal is primarily developed to support GAPPless ROMs through websockets, and Signal calls depend on GCM and proprietary serverside software, then shouldn't the call icon and functionality be stripped from the program?
@rodneyrod
shouldn't the call icon and functionality be stripped from the program?
Please look at #72
Using "LibreSignal" from eutopia.cz/experimental/fdroid/repo Version: 3.3.1-websocket
Calling does not work between websocket and GCM, I have not tested websocket <--> websocket, gcm <--> gcm works.
On the GCM end, the call continues to ring until failure. On the websocket end, the call starts and then immediately fails.
Any idea if this will ever work?