[Free-RTC] Introduction and request for help

Sat Sep 21 20:54:19 CEST 2013

On Sat, Sep 21, 2013 at 10:25:44AM +0300, Emil Ivov wrote:
> On 21 Sep 2013 02:22, "Bas Wijnen" <wijnen at debian.org> wrote:
> 
> > Jitsi (SIP and XMPP): Jitsi is written
> > in Java, which seems to be a
> > problem on its own.
> 
> Well, I am afraid there's no changing this, so if you have an aversion to
> the language, you would simply need to use something else.

I didn't mean to suggest it should be changed.  I was just getting frustrated
that nothing worked, and a program which throws errors before it even started
isn't helping. ;-)

I'm guessing that it's tested using a different java than I have (I'm just
guessing it doesn't throw these errors when the developers run it).  And that
matters more than it should.

Also:

On Sat, Sep 21, 2013 at 09:44:30AM +0200, Daniel Pocock wrote:
> 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.

Which is entirely true.  But it would be good if it would indeed work on all
platforms.  Random crashes are extremely frustrating, especially after trying
so many things for so long, to achieve something which really should be simple.

I mean, what is the big problem?  I have two computers I control.  I can
connect() from one to the other and have a working network connection.  I have
working audio and video hardware on both sides.  How hard can it be to set up a
link to make us see and hear each other?

> 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.

> Empathy is also hard coded to use Google's TURN server, it doesn't use
> the free software TURN servers packaged in Debian.

I consider that a very serious problem.  Google is not exactly known for being
good with privacy.

> > 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

Asterisk does; it just ignores the reported return address and uses
getpeername() instead.  And it works, too; it's used when making a call to an
auto-responder, and that works.

> > 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?

Sure, but perhaps I should first ask if I am right.  In my XMPP account
settings, "Enable Google Contacts search" was on.  I originally also disabled
"Use Google's Jingle" and "Use JingleNodes", but now I see it again, I suppose
that's just technology designed by Google, not actually contacting their
servers.  Or is it?

> > 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?

I did, but on localhost it doesn't care (it works, even if the password is
wrong; of course on localhost I don't need the TURN server anyway, but I had
expected an error nonetheless) and from the masqueraded host it says the
password is wrong even though it isn't.

> 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.

Wait, what?  Do I need to change my DNS records just to start a one-on-one
video call with a computer that can already contact me?  I can do it; I happen
to have control over my DNS, but I really wouldn't expect to need it.

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

Yes, I'm using those already.  Unfortunately Ubuntu, Mac and Windows aren't
accepting 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.

No, I don't need anything complex, thanks.

> 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

Yes, it looks like it, and it works well so far, except for NAT traversal.  And
its documentation is fantastic (except that its focus is not where I needed it).

> 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.

While I understand your reasoning, the usual way in Debian is not to change
anything once it is released, except for security and really urgent things
(virus definition updates; timezone changes).  If you have a much better
version of the package, it might be considered for the next point release, but
not for stable itself.  The downside of this method is that stable is always
outdated (you're left with the state when it was frozen).  The upside is that
it means things are indeed really stable (new "fixes" often introduce new bugs
as well).

Anyway, to get back on topic, all this doesn't matter for me, as I'm running
the TURN server on unstable, so I have version 1.8.13-1.

I see you have uploaded 1.9.0~beta1-1 to experimental, at high urgency, with no
information in the changelog why this was so urgent.  Is there a big difference
with 1.8.13?  Why didn't you upload to unstable?

> You can view the commented version of the file here:
> 
> https://github.com/resiprocate/resiprocate/blob/master/reTurn/reTurnServer.config

The comments didn't make it to unstable, indeed.  Thanks.

> 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

It seems to be the same in sid, looking at the config file?

> 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.

I would definitely like that.  My main goal would be that two people, where at
least one of them is reachable on a public IP (which may not be the IP the host
thinks it has), can make an encrypted video call by:
- both installing a package
- one person filling in the IP (and possibly the name) of the other person
and nothing more.  They should not need to set up any server, and they
certainly shouldn't need to edit DNS entries.

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

I'll do that.

Thanks,
Bas