[jitsi-dev] High CPU load, SSL certificate warning and no XMPP Video call to Mac S-C


#1

Dear list,

i am using the SIP-Communicator only with a local XMPP server and got some
small issues.

My system: Ubuntu 10.04 64bit, Intel i5 CPU, 4GB Ram, Sun Java package

1. High CPU load:
As soon as i start a videocall with the h264 codec, my cpu load goes up to
about 80%. The video is lagging pretty bad (up to 5 seconds) and the audio
takes about 1-2 seconds.
Only the h263-1998 codec is helping and the video lagging goes down to
about a second and the audio arrives instantly. The cpu load goes down to
50% but is still quite high.
Are there any more codecs that i can try?

2. No XMPP videocall to SIP-Communicator on a Mac OS X:
Any call from my Ubuntu system to a Mac fails with the error "Remote is
busy". But any call from the Mac to my system is working just fine.
Unfortunately i couldnt find any more errors/information in the logfiles

2. SSL certificate warning:
Our Lan-Only-XMPP server is using a self signed ssl certificate and of
course the S-C is warning the user about it. But unfortunately it does it
every time i start the client. Is there a way to accept this specific
certificate after the first warning?

Thx
Ben


#2

Hi Ben,

ยทยทยท

On Wed, Feb 9, 2011 at 9:52 AM, Ben <taris@gamersplace.de> wrote:

Dear list,

i am using the SIP-Communicator only with a local XMPP server and got some
small issues.

My system: Ubuntu 10.04 64bit, Intel i5 CPU, 4GB Ram, Sun Java package

1. High CPU load:
As soon as i start a videocall with the h264 codec, my cpu load goes up to
about 80%. The video is lagging pretty bad (up to 5 seconds) and the audio
takes about 1-2 seconds.
Only the h263-1998 codec is helping and the video lagging goes down to
about a second and the audio arrives instantly. The cpu load goes down to
50% but is still quite high.
Are there any more codecs that i can try?

2. No XMPP videocall to SIP-Communicator on a Mac OS X:
Any call from my Ubuntu system to a Mac fails with the error "Remote is
busy". But any call from the Mac to my system is working just fine.
Unfortunately i couldnt find any more errors/information in the logfiles

2. SSL certificate warning:
Our Lan-Only-XMPP server is using a self signed ssl certificate and of
course the S-C is warning the user about it. But unfortunately it does it
every time i start the client. Is there a way to accept this specific
certificate after the first warning?

About this you can accept the certificate permanently by selecting
"Show certificate" and then checking "Always trust ...."

Cheers
damencho


#3

Hi Ben,

As soon as i start a videocall with the h264 codec, my cpu load goes up to about 80%. The video is lagging pretty bad (up to 5 seconds) and the audio takes about 1-2 seconds.<

My experience is the other way around: My video is always fluent and instant - there are virtually no delays. What's lagging is the audio. It can take up to 5 seconds and longer rendering a conversation impossible.

Especially, if the machine is not a powerhouse. My tests failed completely with my netbook (Atom) and a P IV with around 1.6GHz on Windows. Always - the sound starts lagging as soon as I turn on the camera or shared desktop.

My system: Ubuntu 10.04 64bit, Intel i5 CPU, 4GB Ram, Sun Java package

That should be more than enough.
I have an Intel P5 with 3.5Ghz and a slightly faster AMD. Both work pretty good. I had to replace OpenJDK by the Sun Version on both sides.

On the AMD I had to uninstall PulseAudio because the audio latency was completely nuts (echo canceller does not work with that) I don't know if this is caused by the AMD or the 64 bit OS (the Intel machine is still 32bit)

Only the h263-1998 codec is helping and the video lagging goes down to
about a second and the audio arrives instantly. The cpu load goes down to
50% but is still quite high.
Are there any more codecs that i can try?

As far as I know - this is it. VP8 us in the Roadmap for Q2/3 2011. I doubt, it will consume less processing power.

H264 is CPU hungry. No doubt about it. However encoding experience with other video applications shows, that a smaller video format (smaller size or less fps) has sometimes a better user experience. So it might be an advantage to be able to set a smaller video format. But until now, there is no such option - at least not for the user.

Greetings
Conrad


#4

Hi Damian,

2. SSL certificate warning:
Our Lan-Only-XMPP server is using a self signed ssl certificate and of
course the S-C is warning the user about it. But unfortunately it does

it

every time i start the client. Is there a way to accept this specific
certificate after the first warning?

About this you can accept the certificate permanently by selecting
"Show certificate" and then checking "Always trust ...."

*doh* ..i didn't see the checkbox even after looking at the certificate
couple of times :wink:

Just for the usability i suggest that the checkbox should be moved next to
the buttons at the very bottom of the window.
Between the upper text and the certificate itself most of the user
probably overlook the checkbox.

Thanks for the hint :slight_smile:


#5

Just for the usability i suggest that the checkbox should be moved next to
the buttons at the very bottom of the window.
Between the upper text and the certificate itself most of the user
probably overlook the checkbox.

Most users _hopefully_ overlook the checkbox and don't even continue at all. I'm aware of the need of self-signed certificates, but if you deploy it to a larger group you should probably consider using either a real certificate or pre-installing your self-signed cert to the local truststore.

Regards,
Ingo


#6

Just for the usability i suggest that the checkbox should be moved next
to
the buttons at the very bottom of the window.
Between the upper text and the certificate itself most of the user
probably overlook the checkbox.

Most users _hopefully_ overlook the checkbox and don't even continue at

all.

Well, from the usability point of view it should be, imho, changed the way
i described.

From the security point of view it probably should be removed.

You can never make it perfect, but as long as you need couple of clicks to
permantly add the certificate it "should" be enough for any aware user that
there is something strange going on - anybody else will do it anyway :slight_smile:

I'm aware of the need of self-signed certificates, but if you deploy
it to a larger group you should probably consider using either a real
certificate or pre-installing your self-signed cert to the local
truststore.

This brings me to a different question i had - where does the
SIP-Communicator look for valid certificates?
Each system, browser, program brings its own pool of certificates ..does
the S-C has something like that, too? Couldn't find anything like that in
the preferences and i was planning to create our own CA since this is a
local-network-server only.

Ben


#7

Well, from the usability point of view it should be, imho, changed the way
i described.
From the security point of view it probably should be removed.

The compromise would then be "leave as is" :slight_smile:

This brings me to a different question i had - where does the
SIP-Communicator look for valid certificates?
Each system, browser, program brings its own pool of certificates ..does
the S-C has something like that, too? Couldn't find anything like that in
the preferences and i was planning to create our own CA since this is a
local-network-server only.

It uses the local Java truststore (by default "C:\Program Files\Java\jre6\lib\security\cacerts") and if you select "always trust" it stores the cert in its own truststore in %appdata%\SIP Communicator\jssecacerts

The Linux-Paths are probably distro-dependent.

Ingo