[Free-RTC] Introduction and request for help

Mon Sep 23 13:52:18 CEST 2013

On Sat, Sep 21, 2013 at 10:38 PM, Derek LaHousse <dlahouss at mtu.edu> wrote:
> Bas,
> Have you checked out WebRTC at all?  If you've got some of the latest
> Firefox or Chrome (maybe others) builds, you can try apprtc.appspot.com
> to meet your immediate goal.

Except for the fact that there is no reliably end-to-end encryption there.

This is a problem with WebRTC altogether.

Emil

> Derek
>
> On Sat, 2013-09-21 at 20:54 +0200, Bas Wijnen wrote:
>> 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
>> _______________________________________________
>> Free-RTC mailing list
>> Free-RTC at lists.fsfe.org
>> https://lists.fsfe.org/mailman/listinfo/free-rtc
>
> _______________________________________________
> Free-RTC mailing list
> Free-RTC at lists.fsfe.org
> https://lists.fsfe.org/mailman/listinfo/free-rtc

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
emcho at jitsi.org                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31