[jitsi-dev] Slashdot: Linux-Friendly Alternatives To Skype


#1

The review referenced by Slashdot actually lists Jitsi as one of the
"5 Skype alternatives for Linux users".


#2

#3

True - however, the review was not very friendly though :frowning: . The
reviewer found some stuff he thinks was not so good.

To me this person didn't really tested/reviewed Jitis's features, maybe
he was annoyed by the loading/startup time, the sheer number of features
to use/to configure. No words about the security features, etc.

IMHO we need to spread word and distribute links to the Jitsi home page
which is really impressive :slight_smile: .

Maybe we can also have a look at the items the reviewer criticized (albeit
they are very generic in the review).

Best regards,
Werner

···

Am 19.05.2011 23:07, schrieb Lyubomir Marinov:

The review referenced by Slashdot actually lists Jitsi as one of the
"5 Skype alternatives for Linux users".


#4

It was thanks to that review in slashdot that I found jitsi.

Ekiga didn't work for me. Gnu-telephony is still in alpha phase and for the
google services, I'm not in the USA. So I arrived at jitsi. Although the
comments were negative, I didn't care because I don't need it to work with
Ekiga (google doesn't work with Ekiga either) and speed: many people say
java is so slow, but I know some Java and I used it a lot. Only the startup
can be slow, and I didn't care about the startup. So if you leave out those
negative things, you are left with the best review of the bunch.

Regards,
Sander

···

2011/5/21 Werner Dittmann <Werner.Dittmann@t-online.de>

Am 19.05.2011 23:07, schrieb Lyubomir Marinov:
> The review referenced by Slashdot actually lists Jitsi as one of the
> "5 Skype alternatives for Linux users".
>
True - however, the review was not very friendly though :frowning: . The
reviewer found some stuff he thinks was not so good.

To me this person didn't really tested/reviewed Jitis's features, maybe
he was annoyed by the loading/startup time, the sheer number of features
to use/to configure. No words about the security features, etc.

IMHO we need to spread word and distribute links to the Jitsi home page
which is really impressive :slight_smile: .

Maybe we can also have a look at the items the reviewer criticized (albeit
they are very generic in the review).

Best regards,
Werner


#5

I dont really see it as a good review. Why?

He starts with Ekiga, a program that has some real flaws in NAT traversal and such (also i hear the service uses some not very good NAT traversal techniques).
Put it plainly, there is a good chance it wont work. Typical issue is no sound on either side of the conversation. And this happens even with SIP servers that are in a routed environment, not to talk about connecting to ekiga.net from behind a firewall.

I evaluated pretty much all free SIP/Voip alternatives available to Linux about 2 years ago and i still try their recent versions. Then we needed some working solutions for a SIP server (TrixBox) hosted in our company's internal network and we accessed it either in the local network or via OpenVPN (from home and other locations).

I use Sip Communicator myself since then because it is the most complete Instant messaging app out there. But for the company SIP i recommended Linphone because that has a stable version and for SIP (and only SIP) its great.

My list of SIP clients:
Linphone/YATE client/Sflphone/Jitsi - very reliable as far as SIP connectivity goes
Ekiga (version 3xxx)/Qutecom - these appear everywhere on the net in reviews but for me they didnt quite work - Qutecom could not even connect if i used my server through a routed VPN connection and Ekiga was a hit-and-miss, leaving me without sound randomly (on our SIP server and would not even connect to ekiga.net if i was behind the companys firewall - interestingly Linphone/Sflphone worked better with ekiga.net accounts).

My review of Jitsi (Debian/Ubuntu):

1. The good and excellent:

As for the recent builds and the Google Talk/Jabber protocol improvements, Jitsi has stable and reliable voice/video calls (minus the issues enumerated in the "next section) via Google Talk and Jabber (tested on an OpenFire server).

There is however a few seconds of waiting until the zrtp connection is completed - during this time you may or may not have bidirectional audio - i think the users should be informed that they should wait on both ends for the appeareance of the zrtp key&padlock, as some with less patience will say that the feature is buggy.

But for me every single time this handshake was completed, i had bidirectional and reliable connection.

Not one random hangup. Call sound quality on my side was 100% good (the other side reported some crackling sometimes, but rarely though). Once i had to restart Jitsi after a screen sharing session ending locked it up (i was the receiving party, the other side had no issues).
I used the ilbc codec that uses 7-9 KB/s and i just discovered the GSM codec that seems to use about 3-4 KB/s bandwidth (not tested its quality yet though).

All in all Jitsi has the "reliable" click-and-work feeling for me for google talk account voice/video and SIP. Also the bandwidth was 7-9 KB/s for voice with the ilbc codec (the GSM codec seem to fare better at a whopping 3-4 KB/s, but not tested it yet thouroughly). Skype had 5-8 KB/s, so not a big difference - i was able to operate both even on broadband.

2. Things that need to be improved:

- there is the issue of having many updates, and these sometimes broke this or that - this means that Jitsi is not a good program for someone who needs something that is stable and dependable. A stable version with pre-tested commits is very needed.

- I still dont see the PulseAudio/PortAudio issues sorted out - I recently recommended Jitsi for someone to try on Ubuntu 10.04 or 10.10 and he said that it was using 100% CPU in a test call - that was my exact problem with it in the time i used PulseAudio (random high CPU usage in calls). PulseAudio is gaining momentum as i have seen it so the devs should really have a look into this issue.

- there is a need of documentation regarding account set-up - i have no idea what those security-related features really mean - i just tick them all where i install Jitsi because i know they work that way. But i would very much like to know what those mean.
Also, the used codecs setup gave me a headache when i could not use certain IVR's calling from our SIP server - until by chance i stumbled accross the solution somewhere on the Jitsi lists - disabling the telephone-event "codec" solved the issue. So, please include a descriptions of these aswell.

- the ZRTP options were all disabled by default 2 days ago in a build (installed it first time on a Debian system) and calls were failing because of it (google talk) - had i not tried and tested Jitsi's options before i would never knew what was going on ( i solved it by ticking all boxes under all security tabs...). Please provide some good starter zrtp options and more description of th errors if calls are failing.
Or perhaps an autoconfiguration prompt of ZRTP if there are differences between the 2 parties?

- File transfers - this is a real issue for me - purely and simply they dont really work via google talk/jabber (or are restricted to 39 KB/sec). With other Jabber clients such as Pidgin they downright fail. And i assume others will have this issue too. I started a bug report but was dismissed as "incomplete". Please reply to me if possible and tell me what i need to test exactly.

- Screen sharing - while it generally works, this feature need to be debugged - sometimes it hangs Jitsi when the sending party cancels the sharing.
Screen sharing is slow to transfer the whole desktop - for about 10-15 seconds the receiving party sees a grey screen - after that it starts to work, but i fel its a long time - somewill say that it is not working because of this. This applies to webcams too.
The h263 codec produces awful pictures - very blurry, not very usable (the h264 is good though).
The "remote control" feature is great but sometimes works sometimes the clicks are ignored, it is not really reliable as it is now. Although it would be a killer feature if stabilized.

- Protocol incompatibilities that should be looked at:
the first here is naturally Google Talk (web plugin, windows client) AND the ability to call out from the Google talk account - i see this interoperability as an essential feature (also i know that it is worked on).
Another would be Ekiga - maybe i am not really convinced about this as google talk (or jabber & co) are far superior to it and have more features. It is nevertheless in every voip review so adding support for it would not hurt and the users that want to use the Ekiga services will be able to do so.

- User list: please make possible to see the whole status messages of the users along with their avatars on our contact list on mouse hover, and make it appear in the right click menus "Contact info" - and here to be copyable and the web links marked as such and to open on click. This applies to all protocols.

Wishlist: Yahoo voice/video calls - here in Romania (and not only) most people have Yahoo addresses and use Yahoo Messenger for Voip. So naturally a cross platform client that supports voice/video in the Yahoo network (+ compatible with the Windows client) would rock and be an instant win for many many people worldwide. (Correct me that i am wrong, but i know of no other client besides the proprietary Windows one to suport voice/video with Yahoo accounts right now.)

···

On Sat, 21 May 2011 08:32:05 +0200 Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Am 19.05.2011 23:07, schrieb Lyubomir Marinov:
> The review referenced by Slashdot actually lists Jitsi as one of the
> "5 Skype alternatives for Linux users".
>
True - however, the review was not very friendly though :frowning: . The
reviewer found some stuff he thinks was not so good.

To me this person didn't really tested/reviewed Jitis's features, maybe
he was annoyed by the loading/startup time, the sheer number of features
to use/to configure. No words about the security features, etc.

IMHO we need to spread word and distribute links to the Jitsi home page
which is really impressive :slight_smile: .

Maybe we can also have a look at the items the reviewer criticized (albeit
they are very generic in the review).

Best regards,
Werner

--
Regards,

Kertesz Laszlo


#6

Hey Kertesz,

Thank you for your review. A few comments inline.

На 21.05.11 11:39, Kertesz Laszlo написа:

On Sat, 21 May 2011 08:32:05 +0200 I dont really see it as a good
review. Why?

He starts with Ekiga, a program that has some real flaws in NAT
traversal and such (also i hear the service uses some not very good
NAT traversal techniques). Put it plainly, there is a good chance it
wont work. Typical issue is no sound on either side of the
conversation. And this happens even with SIP servers that are in a
routed environment, not to talk about connecting to ekiga.net from
behind a firewall.

I evaluated pretty much all free SIP/Voip alternatives available to
Linux about 2 years ago and i still try their recent versions. Then
we needed some working solutions for a SIP server (TrixBox) hosted in
our company's internal network and we accessed it either in the local
network or via OpenVPN (from home and other locations).

I use Sip Communicator myself since then because it is the most
complete Instant messaging app out there. But for the company SIP i
recommended Linphone because that has a stable version and for SIP
(and only SIP) its great.

My list of SIP clients: Linphone/YATE client/Sflphone/Jitsi - very
reliable as far as SIP connectivity goes Ekiga (version 3xxx)/Qutecom
- these appear everywhere on the net in reviews but for me they didnt
quite work - Qutecom could not even connect if i used my server
through a routed VPN connection and Ekiga was a hit-and-miss, leaving
me without sound randomly (on our SIP server and would not even
connect to ekiga.net if i was behind the companys firewall -
interestingly Linphone/Sflphone worked better with ekiga.net
accounts).

My review of Jitsi (Debian/Ubuntu):

1. The good and excellent:

As for the recent builds and the Google Talk/Jabber protocol
improvements, Jitsi has stable and reliable voice/video calls (minus
the issues enumerated in the "next section) via Google Talk and
Jabber (tested on an OpenFire server).

There is however a few seconds of waiting until the zrtp connection
is completed - during this time you may or may not have bidirectional
audio - i think the users should be informed that they should wait on
both ends for the appeareance of the zrtp key&padlock, as some with
less patience will say that the feature is buggy.

This delay is more likely cause by the ICE connection establishment
rather than ZRTP. Depending on the network interfaces and addresses you
have, this can take up to several seconds (that's why you'd only get it
with XMPP).

ZRTP does nothing to prevent audio from playing. It can't afford to,
because when it starts the handshake it has no way of knowing whether it
would be able to complete.

That's why it lets unencrypted comm through and then plays an audio
signal once you are safe.

But for me every single time this handshake was completed, i had
bidirectional and reliable connection.

Not one random hangup. Call sound quality on my side was 100% good
(the other side reported some crackling sometimes, but rarely
though). Once i had to restart Jitsi after a screen sharing session
ending locked it up (i was the receiving party, the other side had no
issues). I used the ilbc codec that uses 7-9 KB/s and i just
discovered the GSM codec that seems to use about 3-4 KB/s bandwidth
(not tested its quality yet though).

All in all Jitsi has the "reliable" click-and-work feeling for me for
google talk account voice/video and SIP. Also the bandwidth was 7-9
KB/s for voice with the ilbc codec (the GSM codec seem to fare better
at a whopping 3-4 KB/s, but not tested it yet thouroughly). Skype had
5-8 KB/s, so not a big difference - i was able to operate both even
on broadband.

2. Things that need to be improved:

- there is the issue of having many updates, and these sometimes
broke this or that - this means that Jitsi is not a good program for
someone who needs something that is stable and dependable. A stable
version with pre-tested commits is very needed.

Agreed and we'll be working on this in the following couple of weeks. At
least in the beginning, the plan is to simply grab a development build
every now and then and push it into the stable line. At this point I'd
like to avoid branching SVN for every release. While it is a good
practice, I am simply afraid that the effort required for this would
kill the entire process. This may change in the future when we are able
to dedicate more resources to QA.

We'll be trying to push an update no more than once per month (unless
major issues require otherwise) and we should also be able to prevent
most of the breakers from getting out there.

- I still dont see the PulseAudio/PortAudio issues sorted out - I
recently recommended Jitsi for someone to try on Ubuntu 10.04 or
10.10 and he said that it was using 100% CPU in a test call - that
was my exact problem with it in the time i used PulseAudio (random
high CPU usage in calls). PulseAudio is gaining momentum as i have
seen it so the devs should really have a look into this issue.

The only reason why we (BlueJimp) haven't looked into this issue is that
none of us is able to reproduce it and in these circumstances ... well
there's absolutely no way for us to even begin to fix it.

I am aware that many people are having it and if at any point someone in
BlueJimp manages to get a reliable reproduction, we're definitely going
to dig into it.

Until then, if anyone else is willing to have a look - we'd be more than
happy to commit patches.

- there is a need of documentation regarding account set-up - i have
no idea what those security-related features really mean - i just
tick them all where i install Jitsi because i know they work that
way. But i would very much like to know what those mean. Also, the
used codecs setup gave me a headache when i could not use certain
IVR's calling from our SIP server - until by chance i stumbled
accross the solution somewhere on the Jitsi lists - disabling the
telephone-event "codec" solved the issue. So, please include a
descriptions of these aswell.

As I mentioned on the users list - Werner sent me a ZRTP FAQ a while
back and we should get it on jitsi.org as soon as possible. It is my
fault it is not already there.

Until then - not doing anything in terms of ZRTP configuration is the
way to go. It's shipped the way it's supposed to be. I also noticed
recently that the form shows all boxes unchecked by default but I
believe this is a rendering problem with the form itself. We'll have a
look but the best thing to do would be to probably move the majority of
the options there into an "Advanced" sub-form of some sort as they are
not meant for regular users.

(Werner, please correct me if I am wrong)

- the ZRTP options were all disabled by default 2 days ago in a build
(installed it first time on a Debian system) and calls were failing
because of it (google talk) - had i not tried and tested Jitsi's
options before i would never knew what was going on ( i solved it by
ticking all boxes under all security tabs...). Please provide some
good starter zrtp options and more description of th errors if calls
are failing. Or perhaps an autoconfiguration prompt of ZRTP if there
are differences between the 2 parties?

- File transfers - this is a real issue for me - purely and simply
they dont really work via google talk/jabber (or are restricted to 39
KB/sec). With other Jabber clients such as Pidgin they downright
fail. And i assume others will have this issue too. I started a bug
report but was dismissed as "incomplete".

Right, sorry for that, however we do the same with most of the issues
that are filed without a prior discussion here or on IRC.

We currently have support for in-bind file transfer with XMPP. Google
would often block this or limit bandwidth or file size.

In order to have reliable file transfer over Google, we'd need to
implement support for the Google File Transfer protocol (which also
includes support for Pseudo TCP). You may enter a feature request for
that if you wish.

In order to have proper file transfer on other XMPP servers we'd need
Jingle file transfer. You may enter a separate feature request for that
too if you wish.

Note that both of these are relatively complex so it may take a while
for us to get to them.

Please reply to me if
possible and tell me what i need to test exactly.

- Screen sharing - while it generally works, this feature need to be
debugged - sometimes it hangs Jitsi when the sending party cancels
the sharing. Screen sharing is slow to transfer the whole desktop -
for about 10-15 seconds the receiving party sees a grey screen -
after that it starts to work, but i fel its a long time - somewill
say that it is not working because of this. This applies to webcams
too. The h263 codec produces awful pictures - very blurry, not very
usable (the h264 is good though). The "remote control" feature is
great but sometimes works sometimes the clicks are ignored, it is not
really reliable as it is now. Although it would be a killer feature
if stabilized.

It would help if you could describes steps to reproduce and even better
if you could accompany them with logs.

- Protocol incompatibilities that should be looked at: the first here
is naturally Google Talk (web plugin, windows client) AND the ability
to call out from the Google talk account - i see this
interoperability as an essential feature (also i know that it is
worked on).

Yes we also find it essential, and yes, we are currently working on it.

Another would be Ekiga

I suppose you mean: ekiga.net and if so it is extremely unlikely that we
will ever use STUN obtained public addresses in SIP messages.
Implementing ICE for SIP is on our roadmap but even that won't fix the
problem.

To my recollection ekiga.net run an open service so it would be far
simpler to simply connect to iptel.org or ippi.fr and call people on
ekiga.net from there if you really need to.

- maybe i am not really convinced
about this as google talk (or jabber & co) are far superior to it and
have more features. It is nevertheless in every voip review so adding
support for it would not hurt and the users that want to use the
Ekiga services will be able to do so.

- User list: please make possible to see the whole status messages of
the users along with their avatars on our contact list on mouse
hover, and make it appear in the right click menus "Contact info" -
and here to be copyable and the web links marked as such and to open
on click. This applies to all protocols.

I remember seeing something from you on that matter previously. Could
you please open an enhancement for this if you haven't already done so?
Of course a patch would be most welcome.

Wishlist: Yahoo voice/video calls - here in Romania (and not only)
most people have Yahoo addresses and use Yahoo Messenger for Voip. So
naturally a cross platform client that supports voice/video in the
Yahoo network (+ compatible with the Windows client) would rock and
be an instant win for many many people worldwide. (Correct me that i
am wrong, but i know of no other client besides the proprietary
Windows one to suport voice/video with Yahoo accounts right now.)

Those are also on my personal wish lis. We'll probably be adding Windows
Live support at some point this year (or next) and Yahoo! would come next.

Cheers,
Emil