[Free-RTC] Introduction and request for help

[Bas Wijnen]

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