First of all, thanks for the replies. I know I sound frustrated (that's because I am :-P), but I'm very happy that you guys are trying to help me to get it working.
On Mon, Sep 23, 2013 at 02:50:47PM +0300, Emil Ivov wrote:
Exceptions printed by Jitsi on stderr are often mostly meant as debug output and you should really worry about them unless you know exactly what they mean.
That sounds sort of acceptable (although in that case they really should be switched on with a switch, not be printed by default), but this doesn't look harmless:
Auto-properties install: reference:file:sc-bundles/galagonotification.jar (org.osgi.framework.BundleException: Unable to cache bundle: reference:file:sc-bundles/galagonotification.jar - java.io.IOException: Referenced file does not exist: sc-bundles/galagonotification.jar) org.osgi.framework.BundleException: Unable to cache bundle: reference:file:sc-bundles/galagonotification.jar at org.apache.felix.framework.Felix.installBundle(Felix.java:2703) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:165) at org.apache.felix.main.AutoProcessor.processAutoProperties(AutoProcessor.java:296) at org.apache.felix.main.AutoProcessor.process(AutoProcessor.java:79) at org.apache.felix.main.Main.main(Main.java:292) at net.java.sip.communicator.launcher.SIPCommunicator.main(SIPCommunicator.java:153) Caused by: java.io.IOException: Referenced file does not exist: sc-bundles/galagonotification.jar at org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation(BundleArchive.java:852) at org.apache.felix.framework.cache.BundleArchive.reviseInternal(BundleArchive.java:550) at org.apache.felix.framework.cache.BundleArchive.<init>(BundleArchive.java:153) at org.apache.felix.framework.cache.BundleCache.create(BundleCache.java:277) at org.apache.felix.framework.Felix.installBundle(Felix.java:2699) ... 5 more Auto-properties start: reference:file:sc-bundles/galagonotification.jar (org.osgi.framework.BundleException: Unable to cache bundle: reference:file:sc-bundles/galagonotification.jar - java.io.IOException: Referenced file does not exist: sc-bundles/galagonotification.jar)
(And then there's some other stuff, which claims to be SEVERE, but probably is harmless.)
Also, the program is actually crashing when I do nothing special (for example, click on a tab in the account settings; this just happened once and is not reproducible, but it regularly crashes at random moments).
OK. If we had to really quote one big problem then I suppose it would be "diversity". Diversity in hardware, diversity of OSes and OS flavors, diversity of audio/video capture/render libs, diversity in devices and of course, diversity in network topologies.
That makes sense, but all parts seem to be working: I have video and audio hardware which works to show images on my local screen and to record audio from. I have a network which is capable of making connections between all clients and the server I want to use. Currently, I even find it acceptable if the client which is behind a NAT cannot get inbound connections.
As far as I can see, that means that all the parts are working. I cannot understand how there can be almost 10 things to choose from, and none of them manages to just combine the parts and make it work.
Note that RTC applications are not generally written for the use case you describe: two machines with direct IP connectivity. This is simply one of the multitude of cases where RTC has to work.
Sure. But it is the simplest possible case; all the other cases use all the parts I need, and possibly more. If there's a problem with the network or the audio/video hardware, nothing works. So if anything works, it should be my case.
To be more clear: this isn't what I actually want. This is what I'd be happy with by now. What I actually want is a video telephone, which I can use to call and be called, send text messages (and voice/video mail; why not), and all that with other people using a multitude of OSs. Oh, and conference calls would be nice, too. But nothing works, so I say I'm happy to start small and accept it if only Debian works, with just two computers that can directly reach each other. That really shouldn't be too much to ask, I would think.
I haven't seen you describing a specific problem (other than the language of the application and the fact that you find standard output to be unsettling) so it's hard for me to be any more specific on your situation.
Specific problems:
1. With empathy, if I try to set up an audio or video connection, it says "there was an error starting the call". It doesn't say what sort of error, or what I can do to fix it. When I run wireshark I see it doesn't even send anything out to the network. If I call myself from another machine (with another account), I get a call request, but when I try to answer it again says there was an error starting the call without any specifics.
2. With gajim, things seem to work pretty well, except that it doesn't allow me to select audio or video calls. It says I need a package for it, but when I install that it still doesn't allow me. It doesn't say why.
3. With jitsi, the buttons for audio and video call are greyed out.
4. With pidgin, making a call to jitsi results in a null pointer exception for jitsi. Being called by jitsi is now possible and works, but even though jitsi reports sound input (in its volume indicator), pidgin doesn't report receiving any sound (and I don't hear anything). The other way it works, so I do get sound from pidgin to jitsi when jitsi starts the call. However, that's audio. If I try to make a video call, I just get an audio call instead, with no explanation why.
5. Pidgin to pidgin seems to work slightly better; I am able to make a video call, and both cameras show with their LED that they are active, but I see only black rectangles, no actual video (even locally). Also, sound doesn't work at all.
If there are any other combinations you want to hear, let me know and I'll send you the results. The most depressing parts are IMO: - Pidgin sometimes hangs when trying to hang up the connection. I need to use kill -9 to close it. - Jitsi gives null pointer exceptions and crashes randomly.
Things not working isn't pleasant. But hanging and crashing is a step further; this really shouldn't happen.
Since upgrading to wheezy, I can't communicate reliably with Empathy. This is a big no-no for any communications product, once people lose faith in it, it is very hard to recover
In their favor, there aren't any working alternatives. Which isn't a good thing, of course.
It also isn't true.
Sure it isn't. But for me it is. I've been trying for _years_ (with long pauses) to get this working. I'm a programmer, I'm really good with computers, and I can't figure it out. That is very very bad.
And when I ask on an FSFE list for how to make things work, I get a recipe. That's good, but what does it include? Please install Oracle's (non-free) Java, because that's the only one that works. What? So I ask "how can I get this running on free software?" and the answer is "please install this non-free program"? I appreciate the attempt to help, I really do. But if I want to sacrifice my freedom and privacy for making this work, I'll install Skype. And I would have done so years ago.
I don't know if they support ICE with SIP
Asterisk does;
No, I don't think that's true either. At least not in the way Daniel meant it. Asterisk is a Back-to-Back User Agent (B2BUA). It is meant to be an endpoint. As such it is not really meant to let endpoints talk directly to each other. Asterisk being in the middle of all communication is its default mode of operation.
That is true. If you make a connection through asterisk, you really set up two SIP connections; one from each caller to asterisk. But on each of those connections, ICE is supported. Or perhaps I'm misunderstanding what ICE is; I understood it is more or less synonymous with "NAT-traversal" (with some protocol details on how to accomplish it).
Can you raise a bug against the package listing those things you had to disable?
Sure, but perhaps I should first ask if I am right. In my XMPP account settings, "Enable Google Contacts search" was on.
This option is only used in case you actually have a Google account. It has no impact otherwise.
Ok, that is good. It would be even better if that was clear for the user who has to choose what to do with this setting.
I originally also disabled "Use Google's Jingle"
This wouldn't hurt. Although, once again, Jitsi only uses this variant of the Jingle protocol in case it detects that you are using a Google account.
Ah, then I totally misunderstood what that option meant. First I thought it meant "Use Jingle (whatever that is), as offered by Google, sending whatever data it needs through Google's servers". I disabled it for that reason. Then after reading about Jingle, I thought it might mean "Use Jingle (which was designed by Google)" for connections. I would enable that.
But if I understand you correctly, it really means "Use Google's variation of Jingle, which only works if you're talking to Google and won't be used even if you switch this option on, unless you are actually connected to Google".
As you will have guessed, I think this option needs better help text (option name, but perhaps also some mouse-over explanation). I think a separate box with "options only applicable if you use a Google account" might be useful. It would be even better if that box would be greyed out if you're not using a Google account, but I don't know if that can be detected without connecting to the server.
and "Use JingleNodes",
I am interested to know why you chose to do this.
Because I had no idea what it means, and a few lines up it said that Jingle was this Google thing. So I thought it might help to make sure my data isn't sent to Google.
Jingle Nodes is one of the technologies that Jitsi uses for NAT traversal. Disabling it only increases your chances of not being able to establish a connection.
Is there any documentation on it? I'm especially interested in where my data ends up, and who can or cannot read it.
Did you put in the TURN server settings?
I did, but on localhost it doesn't care
Who is it?
I don't understand the question. One of my hosts has a non-masqueraded IP address, so I'm using that one to run the TURN server as well. I tried connecting to it with a client from localhost, but it seems it doesn't even try to use TURN.
I seem to be missing a part of the thread here but, if you are using a TURN server then the client needs to be able to contact it *before* it makes a call.
Yes, it says the password is wrong when trying to set the account to active. The account is set up to use the TURN server, with its password, and the XMPP server, with the user's own credentials. I'm very sure all of them were correct.
Most of the time things would work even if you only had an A record, but yes, you do need to control your DNS.
So what is the DNS entry required for? Which program looks at it, and what happens if it doesn't see the SRV record? Isn't that the same as a missing MX record, that it will just fall back to "same as A"?
Also, if all you need is for two IP-s to talk to each other, then you can simply take VLC and stream your microphone and webcam in each direction. That's a solution specific to your use case.
For this moment, that's a good idea; thank you for the suggestion.
VoIP isn't.
I know, and I eventually want "real" VoIP to work, so even though your suggestion might make my friends happy for now, I still want things to work the proper way.
Protocols like XMPP and SIP and their accompanying methodologies are meant to cover the Internet as a whole. To do that you need to have servers at least at the start of your conversation.
Oh yes, but I have a server which I control. It happens to be the same machine that hosts my side of the connection; that should make things easier, I would think. So that is not a problem. The problem is that I need to know what to install on them and how to configure it to actually make things work.
You might want to download and try Openfire (although, note that it is also written in Java, which may be a problem for you).
I understand how my previous message suggested that I dislike any program written in Java, but that is not the case. My problem with Jitsi is that it seems to not work at all with the Java version that Debian provides. According to the other reply on this list, I really need the non-free version from Oracle.
My problem with Java is that it is so easy for programmers to do that; they write in Java in an attempt to be platform-independent, which is really good, but then there are many different versions, which are not as compatible as they should be, and if the programmers don't watch out, their code only works on non-free stuff. It's nice to have a free software program, but I really want to run it on a free software system as well. With Java, that often fails. That's why I distrust anything written in Java; I have to see that it actually works on my machine before I like it. Jitsi doesn't.
It comes with an easy to install JingleNodes plugin and, together with Jitsi, will give you what you are looking for.
I'll look into it, thanks.
You can also try using http://jit.si to get a feel for how all this works.
Is that just a free XMPP server? I don't need that, I have prosody running on my own host now, and it works (for text anyway). Or is it more?
Thanks, Bas