[Free-RTC] Introduction and request for help

[Daniel Pocock]

On 21/09/13 02:15, Bas Wijnen wrote:
> Hello,
> 
> For some years, I have been trying to set up RTC between machines, with varying
> degrees of succes.  Unfortunately, so far it never really worked; at best it
> worked a bit.  Daniel Pocock recently wrote on a Debian list that he was
> willing to help people with this, so I asked him.  He suggested me (among other
> things) to subscribe here, so I did.
> 
> About me: I'm a member of the Debian project (a "DD"), and I try to run only
> free software on my computers.  I was born and raised in the Netherlands, and
> am currently a graduate student in the USA.  For this reason, my interest in
> RTC got a new push.
> 
> What I want seems simple to me:
> - I want to have audio and video contact with a select group of friends.
> - I have full control over all computers.  They all run Debian GNU/Linux and I
>   can install anything I need.
> - I want all communication to be encrypted.
> - I want no communication to be routed through third party servers (such as
>   Google), apart from the ones which make up the direct connection between the
>   hosts, of course.
> 
> This would all work without problems (I think), except for:
> - All computers in the Netherlands are behind masquerading firewalls over which
>   I have no control.
> 
> That shouldn't be a big problem; there's STUN and TURN and lots of people have
> that problem, so it is certainly solved by now.  Or is it?
> 
> 
> Here are some things I have tried in various combinations, with an explanation
> of the result:
> 
> Ekiga (SIP): video just won't work.  Audio used to work most of the time when I
> was in the Netherlands, but doesn't work nowadays.
> 
> Empathy (XMPP): Using my own jabber server (jabberd14), I have good results
> for text messages and until recently I had good results with audio.  Video is
> totally broken, which seems to be a gstreamer issue: when the other user
> switches their video on, my camera is activated.  Images from long ago are
> interleaved with current images; sometimes with images from slightly less long
> ago, or with the standard "no signal" still image.  The other way (from the
> masqueraed hosts) video used to work sometimes.  Calling only worked one way;
> the other way I could call, but they couldn't pick it up.  Despite all the
> problems, this is by far the best result I've had, where we actually had audio
> contact and even some limited video contact.  Unfortunately, with a recent
> system update I have been unable to have any contact other than text messages
> using Empathy.

Video worked fine in squeeze, I even built Debian Live CDs and gave them
to several people who I communicate with regularly and it was all fine.

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

Empathy is also hard coded to use Google's TURN server, it doesn't use
the free software TURN servers packaged in Debian.  Upstream has not
given feedback on their priority for resolving this issue.  The
resolution simply requires adding some extra config fields in the setup
form so you can choose your own TURN server.

> Empathy (SIP): SIP connections just don't work with masquerading, it seems.
> I've set up an asterisk server, which works as long as no masqueraded hosts are
> using it.  The masqueraded hosts can call the server, get automated answers,
> but cannot be connected to other users (which doesn't make much sense to me,
> because asterisk would pass on all the traffic, so I don't see the difference
> between an automated answer generated by asterisk itself and a real person
> answering).  Anyway, it didn't work well.  Also, Asterisk seems to have very
> limited support for video, but I didn't really get around to trying it out.

I don't know if they support ICE with SIP

> Jitsi (SIP and XMPP): Jitsi is written in Java, which seems to be a problem on
> its own.  When started from a terminal, it spews a lot of warnings and errors,

Java can also be a good thing, as it means users on Linux, Mac and
Windows all get the same code and it is easier for the developers to
make sure that every release is interoperable across all platforms.

For communications software, interoperability is crucial and Java helps
with that.

> but it does seem to work.  Then again, it crashes at random times.  It seems I
> need to disable several settings to make sure it doesn't contact Google; I

Can you raise a bug against the package listing those things you had to
disable?

> really don't like that.  As for how it works: so far it doesn't really (or at
> least not with the masquerated hosts), but perhaps I have to try harder.

Did you put in the TURN server settings?


> As I wrote above, I tried setting up several servers to make things work.  My
> experience so far:
> 
> jabberd14: It takes some trouble to configure it, but it's pretty
> straightforward.  When it's set up, it works.  It supports encrypted messaging,
> which is good.  I'm not sure if the audio and video calls are encrypted as
> well; I'm guessing they might not be.  It would be good if clients would warn
> about this (if my guess is right).
> 
> ejabberd: I just tried setting this up, as Daniel wrote he had been using it
> for years.  I find it very hard to set up, and there is virtually no
> documentation.  It has ejabberdctl, but I had to learn about its existence from
> a web search on how to set the system up.  This really should be a lot less
> painful.  Anyway, I got a local client connected to it now, but I'm trying to
> connect the other client through a local turn server (see below), which doesn't
> work; I think the problem is with the turn server, not with ejabberd.  I tried
> not using the turn server, at which point jitsi crashed and I gave up for now.
> I'll try again later.

Make sure ejabberd works well for chat first

Make sure you have the SRV records, e.g. for pocock.com.au:

_xmpp-client._tcp       IN      SRV     5 0 5222 jabber.trendhosting.net.
_xmpp-server._tcp       IN      SRV     5 0 5269 jabber.trendhosting.net.

>From Debian, you can use CaCert.org certificates and the clients will
trust them.

Multi-domain and IPv6 are slightly tricky, let me know if you need
examples to make them work.  I also have it linked to LDAP.

> asterisk: This seems to work well for what it is intended for: audio only.
> Also, I found it disappointing that the conference room plugin (to make a
> conference call with multiple users) depends on the dahdi plugin, which cannot
> be loaded if you don't have the hardware in your computer.  Anyway, as I wrote
> above asterisk also mysteriously failed to work when used from a masqueraded
> host.  Asterisk's documentation is very complete, but targeted at people who
> want to run a telephone network with hundreds of users, many of which have
> physical SIP phones and want to call other PSTN lines.  This makes it a bit
> hard to read sometimes.

Skip Asterisk for now, it is overkill, and as you point out, no video.

It is very good for building a business phone system though

> resiprocate-turn-server: Daniel wrote I might need this, which makes sense;
> after all, TURN is supposed to solve all problems related to masquerading.  But
> this one is impossible to set up, it seems.  I installed the package; it didn't
> ask any questions, so I hoped it would just work.  It didn't.  I looked at the
> man page (which I found by looking at the list of files installed by the
> package...), but that only gave a link to the project's web page, which has
> surprisingly little information.  The only information about the turn server is
> that there is a config file.  That's still useful, because the man page didn't
> mention it, but really I'd like a "how to use this program" recipe.  Or what I
> really want is that debconf asks me a few questions on install, and I don't
> have to touch anything; it just works.  Anyway, after changing some settings in
> the config file and restarting it, it still doesn't work.  I don't know why
> not.

The config files are fully commented with instructions, but that was
only done after the wheezy freeze began.

The release team have so far not approved further uploads
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717420

but upstream and the package maintainer (myself) are quite happy to
upload those changes when authorised to do so.

You can view the commented version of the file here:

https://github.com/resiprocate/resiprocate/blob/master/reTurn/reTurnServer.config

Note that trunk has slightly changed, the version in wheezy does not
recognise the option "UserDatabaseFile = users.txt" and you need to keep
using a single set of credentials for all users, by specifying something
like this in reTurnServer.config:

LongTermAuthUsername = test
LongTermAuthPassword = password


> Finally, some good news: after all the failures with XMPP and SIP, I looked at
> something entirely different: mumble.  It's written to allow communication
> during multiplayer games, and works fine.  But it doesn't support video,
> doesn't do echo cancellation, and you can't "call" anyone; you must have
> arranged to meet through some other channel.  So certainly not the ideal
> solution, but it's currently the only way I can get working audio
> communication.
> 
> I suppose this story sounds like a lot of misery.  But there is hope: I really
> want it to work, and I want it to work for others as well.  So if you can help
> me to make it work, I'll try to document things, and send patches to Debian
> packages (and upstream, if applicable) to make things better.
> 
> But before I can do that, it has to work for me.  So please advise me on how to
> get there.

I've been getting more recent versions of packages into jessie and I am
very hopeful that with feedback from people like yourself we will be
able to fine tune them further to "just work" and jessie will make a big
impact in this space.

Please put specific comments about the problems into the bug tracker,
that definitely helps us too.

Regards,

Daniel