[Free-RTC] Free-RTC Digest, Vol 10, Issue 3

Tue Sep 24 08:49:42 CEST 2013

Il 23/09/2013 13:52, free-rtc-request at lists.fsfe.org ha scritto:
> Send Free-RTC mailing list submissions to
> 	free-rtc at lists.fsfe.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.fsfe.org/mailman/listinfo/free-rtc
> or, via email, send a message with subject or body 'help' to
> 	free-rtc-request at lists.fsfe.org
>
> You can reach the person managing the list at
> 	free-rtc-owner at lists.fsfe.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Free-RTC digest..."
>
>
> Today's Topics:
>
>     1. Re: Introduction and request for help (Sam Tuke)
>     2. Re: Introduction and request for help (Emil Ivov)
>     3. Re: Introduction and request for help (Emil Ivov)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 23 Sep 2013 12:52:45 +0200
> From: Sam Tuke <samtuke at fsfe.org>
> To: free-rtc at lists.fsfe.org
> Subject: Re: [Free-RTC] Introduction and request for help
> Message-ID: <52401D7D.3020806 at fsfe.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 21/09/13 02:15, Bas Wijnen wrote:
>> Finally, some good news: after all the failures with XMPP and SIP, I looked
>> at something entirely different: mumble...So certainly not the ideal
>> solution, but it's currently the only way I can get working audio
>> communication.
> Same experience here.
>
>> 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.
> WebRTC could maybe fulfill your needs with one configuration or another. There
> are demo sites like http://browsermeeting.com/
>
>> But before I can do that, it has to work for me.  So please advise me on
>> how to get there.
> I'm eagerly anticipating solutions that others here recommend.
>
> Sam.
>
> - -- 
> Sam Tuke
> Campaign Manager
> Free Software Foundation Europe
> IM : samtuke at jabber.fsfe.org
> Latest UK Free Software news: uk.fsfe.org
> Is freedom important to you? Join the fellowship.fsfe.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iF4EAREIAAYFAlJAHX0ACgkQ1bR1Itj7YQXcKgD/e4ULPJLF/Uo1gwvSYjIqfYJe
> S6ofVCnsi72H1iRQmzABAMI+RfZGendbHQjPjflneiDNaIhskNOl5maB0hsor1JR
> =bCkp
> -----END PGP SIGNATURE-----
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 23 Sep 2013 14:50:47 +0300
> From: Emil Ivov <emcho at jitsi.org>
> To: Free real-time-communications discussion list
> 	<free-rtc at lists.fsfe.org>
> Subject: Re: [Free-RTC] Introduction and request for help
> Message-ID:
> 	<CAPvvaaLyYLDT1O97y+X8hhMg5hjxpU5JNNDUoC0mS9JsLfTFFA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sat, Sep 21, 2013 at 9:54 PM, Bas Wijnen <wijnen at debian.org> 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. ;-)
> 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.
>
>> 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.
> It does work for many people.
>
>> I mean, what is the big problem?
> There is no one big problem. It's always about the specifics of the deployment.
>
>> 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?
> 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.
>
> 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.
>
> 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.
>
>>> 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.
>
>>>> 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;
> 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.
>
> As a result, using ICE to establish a direct connection between two
> asterisk connected clients is, as far as I know, not possible.
>
>> 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.
> This option is only used in case you actually have a Google account.
> It has no impact otherwise.
>
>> 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.
>
>> and "Use JingleNodes",
> I am interested to know why you chose to do this.
>
> 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.
>
>> 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
> Who is it?
>
>> (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.
> 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.
>
>>> 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.
> Most of the time things would work even if you only had an A record,
> but yes, you do need to control your DNS.
>
> 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.
>
> VoIP isn't.
>
> 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.
>
>>>  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.
> It actually does handle NAT traversal quite reliably (although not in
> a very bandwidth efficient way due to its always-relay-everything
> model of operation that I mentioned above).
>
>> 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.
> You might want to download and try Openfire (although, note that it is
> also written in Java, which may be a problem for you). It comes with
> an easy to install JingleNodes plugin and, together with Jitsi, will
> give you what you are looking for.
>
> You can also try using http://jit.si to get a feel for how all this works.
>
> Cheers,
> Emil
>
>>> 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
>
>
quick and dirty solution for ejabberd – jitsi –videobridge with turnkey 
ejabberd

dowload a stable version (deb 6) from http://www.turnkeylinux.org/
http://www.turnkeylinux.org/ejabberd

install java
La versione java è 1.6.0_27 (oracle-java6) per debian.
(work only with this vesion of java machine)
After dowload
https://download.jitsi.org/jitsi-videobridge/linux/
configure jitsi videobribge as is explained ( for ejabberd)
https://jitsi.org/Projects/JitsiVideobridgeWithEjabberd

and after you can start to use the service (add –host=127.0.0.1)
https://jitsi.org/Projects/JitsiVideobridge
./jvb.sh --secret=ramones --domain=example.com --port=5275 --host=127.0.0.1

remember that if you do not have the dns configured you can test jitsi 
using

user user at example,com
pwd ….....
but inside of options configure the static ip of ejabberd

options\
modify acccount

folder connection

server options put here the ip address of the server

with this configuration in less than 20 min you can start to use video 
conference with jitsi

I have started to use the new version of turnkeylinux that you can 
download from
sf.net

https://sourceforge.net/projects/turnkeylinux/files/iso/

https://sourceforge.net/projects/turnkeylinux/files/iso/turnkey-ejabberd-13.0rc3-wheezy-amd64.iso/download

but there is some troubleshooting and we need to dkg-reconfigure 
…....... ejabberd

….. this is may work in progress …. with this route map

http://www.rtcquickstart.org/

please if you try to use it (or if something is not clear) send a 
feedback to all

bye
Andrea Celledoni