(bcc announce users)
… with a chapter on Jitsi. The Architecture of Open Source Applications
has just been published. You can buy the book directly from Lulu [0], or
check it out at http://aosabook.org .
All royalties are donated to Amnesty International … unless you get it
from Amazon in which case they would be taking most of it 
…
[0] AOSA @ Lulu ->
http://www.lulu.com/product/paperback/the-architecture-of-open-source-applications/15819207
Not in Amazon.com yet
Not even entering the ISBN number
978-1-257-63801-7
FC
2011/5/26 Emil Ivov <emcho@jitsi.org>:
… unless you get it
from Amazon in which case they would be taking most of it…
На 26.05.11 15:36, Fernando Cassia написа:
2011/5/26 Emil Ivov <emcho@jitsi.org>:
… unless you get it
from Amazon in which case they would be taking most of itNot in Amazon.com yet
Not even entering the ISBN number
978-1-257-63801-7
One more reason to get it from Lulu then 
http://www.lulu.com/product/paperback/the-architecture-of-open-source-applications/15663458
Emil
Hello,
I have a few questions regarding the audio/video codecs used in Jitsi.
1. How does the codec negotiation work between 2 jitsi clients if they have different codec order?
2. There are many codecs there, is there a detailed list about them?
3. Why do some codecs not support zrtp? For example, the GSM codec (that by the way has the lowest bandwidth usage,3-4 KB/s) does not support it it seems (ilbc, speex, dvi/4, pcmu/pcma supports zrtp).
4. Why telephone-event is listed as a codec? Or is it a codec? Because i had to disable it in order to be able to use certain IVRs, if it was enabled, those IVRs (most of them) did not work. (My SIP account has dtmf info set from the server.)
5. What is the purpose of the h263-1998 codec? It produces very blurry images, it seems unusable.
--
O zi buna,
Kertesz Laszlo
Hey Kertesz,
На 27.05.11 07:46, Kertesz Laszlo написа:
Hello,
I have a few questions regarding the audio/video codecs used in
Jitsi.1. How does the codec negotiation work between 2 jitsi clients if
they have different codec order?
We would most likely end up using the first codec from the answer as
recommended by RFC 3264. Your experience may vary from one application
to the other though as it is generally recommended for an answerer not
to change the order from the offer unless they really need to.
Keep in mind that situations where each party streams in a different
codec are also perfectly valid so you may also end up with something
like this.
2. There are many codecs there, is there a detailed list about them?
All the codecs we support are listed in the audio and video preferences.
3. Why do some codecs not support zrtp?
They don't. ZRTP is completely codec agnostic.
For example, the GSM codec
(that by the way has the lowest bandwidth usage,3-4 KB/s) does not
support it it seems (ilbc, speex, dvi/4, pcmu/pcma supports zrtp).
Is it possible that because of the codec your SIP server made you use a
different media path? Do you reproduce the issue with XMPP?
4. Why telephone-event is listed as a codec? Or is it a codec?
It is not, in the sense that it does not allow encoding or decoding
media. It is however one of the RTP payloads that we may end up
streaming if the user sends DTMF events.
Because i had to disable it in order to be able to use certain IVRs,
if it was enabled, those IVRs (most of them) did not work. (My SIP
account has dtmf info set from the server.)
This happened to me once too. Some IVRs return telephone-event as their
highest preference codec. Jitsi tries to use it and fails. It's a bug
with simple workarounds. It would probably be best to open a ticket
nonetheless.
5. What is the purpose of the h263-1998 codec? It produces very
blurry images, it seems unusable.
Some devices only support h.263 and some users prefer low quality rather
than no video at all.
Hope this helps,
Emil
Hello,
The generic Linux installer (the one that has java and everything bundled, .bin format) creates a file instead of installation folder.
If the folder is created beforehand, the installer works.
Also, the program takes large amounts of memory (200 MB or so), but if the run.sh is modified and "-client -Xmx256m" is appended to the command line, it works just as good as the .deb version (in case of Debian) taking ~80 MB at startup.
Can someone verify this?
--
O zi buna,
Kertesz Laszlo
Hello,
I have some issues related to file/folder opening with Jitsi on Debian+Xfce.
On one of my computers in the messaging window, after receiving a file and clicking on its link (Open or Open folder, same result), nothing happens (except the error below).
I have another computer, also running Debian+Xfce, on that one the folder opens with the correct file manager (thunar), but the files open with incorrect associations (that are in the association list, but not set as default).
On both computers, i have no such issues otherwise.
Now i dont know where is the issue here - my Java installation or Jitsi or both.
Can be implemented to specify the file opening method (such as gnome-open, xdg-open, exo-open etc)? Or at least make the file opening methods to follow the configured desktop settings somehow.
And an option to specify the received files save location would be welcome.
Error message when clicking on the "Open Folder" option:
10:25:27.868 SEVERE: util.UtilActivator.uncaughtException().88 An uncaught exception occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: Could not initialize class org.jdesktop.jdic.desktop.internal.impl.GnomeLaunchService
java.lang.NoClassDefFoundError: Could not initialize class org.jdesktop.jdic.desktop.internal.impl.GnomeLaunchService
at org.jdesktop.jdic.desktop.internal.impl.ServiceManagerStub.getService(Unknown Source)
at org.jdesktop.jdic.desktop.internal.ServiceManager.getService(Unknown Source)
at org.jdesktop.jdic.desktop.Desktop.open(Unknown Source)
at net.java.sip.communicator.impl.osdependent.Desktop$JdicDesktopPeer.open(Desktop.java:341)
at net.java.sip.communicator.impl.osdependent.DesktopServiceImpl.open(DesktopServiceImpl.java:75)
at net.java.sip.communicator.impl.gui.main.chat.filetransfer.FileTransferConversationComponent.actionPerformed(FileTransferConversationComponent.java:455)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:272)
at java.awt.Component.processMouseEvent(Component.java:6289)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
at java.awt.Component.processEvent(Component.java:6054)
at java.awt.Container.processEvent(Container.java:2041)
at java.awt.Component.dispatchEventImpl(Component.java:4652)
at java.awt.Container.dispatchEventImpl(Container.java:2099)
at java.awt.Component.dispatchEvent(Component.java:4482)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4577)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
at java.awt.Container.dispatchEventImpl(Container.java:2085)
at java.awt.Window.dispatchEventImpl(Window.java:2478)
at java.awt.Component.dispatchEvent(Component.java:4482)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:644)
at java.awt.EventQueue.access$000(EventQueue.java:85)
at java.awt.EventQueue$1.run(EventQueue.java:603)
at java.awt.EventQueue$1.run(EventQueue.java:601)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:98)
at java.awt.EventQueue$2.run(EventQueue.java:617)
at java.awt.EventQueue$2.run(EventQueue.java:615)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:614)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
--
O zi buna,
Kertesz Laszlo
Can be implemented to specify the file opening method (such as gnome-open, xdg-open, exo-open etc)?
I personally find it very complicated from the user perspective to
have to deal with such a setting, I'd prefer an automatic approach
that "just works". If push comes to shove, I guess I'm OK with having
it implemented without UI and available for configuration through
provisioning.
Or at least make the file opening methods to follow the configured desktop settings somehow.
I'd rather have this than the above.
As I understand these two as alternatives, I'd suggest that you create
an issue so that we can explore the options when we have time.
10:25:27.868 SEVERE: util.UtilActivator.uncaughtException().88 An uncaught exception occurred in thread=Thread[AWT-EventQueue-0,6,main] and message was: Could not initialize class org.jdesktop.jdic.desktop.internal.impl.GnomeLaunchService
java.lang.NoClassDefFoundError: Could not initialize class org.jdesktop.jdic.desktop.internal.impl.GnomeLaunchService
It seems to me that the exception can be looked at while also
exploring the above two so I'd rather have it rolled into the same
issue.
And an option to specify the received files save location would be welcome.
I like the idea to have such a setting in the UI. I think you can
create a feature request for it.
On Sat, May 28, 2011 at 10:39 AM, Kertesz Laszlo <laszlo.kertesz@gmail.com> wrote:
Unfortunately we no longer have the resources to maintain this installer
so if anyone is able to provide consistent maintenance, patches would be
most welcome.
Cheers,
Emil
На 27.05.11 21:13, Kertesz Laszlo написа:
Hello,
The generic Linux installer (the one that has java and everything bundled, .bin format) creates a file instead of installation folder.
If the folder is created beforehand, the installer works.Also, the program takes large amounts of memory (200 MB or so), but if the run.sh is modified and "-client -Xmx256m" is appended to the command line, it works just as good as the .deb version (in case of Debian) taking ~80 MB at startup.
Can someone verify this?