Featured questions (hide)

§ General

§ How do I get the latest Jitsi source code?

You could either svn checkout all of it from the Jitsi SVN repository (see Retrieving and Building the Sources for details) or use one of the nightly source snapshots (check the Download page).

§ How do I become an Observer of the project?

You can get the Observer project role here

§ I’ve discovered a bug, what can I do?

Please, report it to the developers!
Take a look at the Reporting bugs guidelines page describing the steps to report bugs effectively.

§ Where do I find the log files?

The easiest way to get hold of the log files is to save them to a location of your choice using Jitsi’s GUI. You can do so by clicking on Tools→Options, then selecting the “Advanced” tab and opening the “Logging” form. You’ll see the “Archive Logs” button in there.

Check out the screenshot for an even better description.

Important Note: When asked for logs, please make sure that you provide the full set of logs, or better yet, the zip that Jitsi generates when following the above instructions. Please do not send separate files or file snippets as those are likely to be insufficient.

Otherwise, if you really want to know, the log files are located in the log folder residing in:

  • Windows: “%APPDATA%\SIP Communicator” or “%APPDATA%\Jitsi”. On Windows XP and earlier, this path translates to “C:\Documents and Settings\<Windows login/user name>\Application Data\Jitsi” (the folder may also be called SIP Communicator if you first installed Jitsi while it was still called that way). On Windows Vista and 7, it expands to “C:\Users\<Windows login/user name>\AppData\Roaming\Jitsi” or “C:\Users\<Windows login/user name>\AppData\Roaming\SIP Communicator”. Note that these folders are hidden on Windows 2000 and later.
  • Mac OS X: ~/Library/Application Support/Jitsi (again, could SIP Communicator)
  • Linux: ~/.jitsi (or ~/.sip-communicator)

§ How do you spell Jitsi and what does it mean?

The correct spelling of the application name is Jitsi (“jitsi” also works). The origin of the name is Bulgarian (spelled Жици). It means wires and the point is that the application allow you to connect to many network and people just as wires do. Of course no one other than Bulgarians is supposed to know what this means and we picked the name mainly because it was short and sounded well.

§ I’d like to see a new feature in Jitsi, can you do that for me?

Yes, developers take into account feature requests. First of all you’ll need to email directly the development list and describe in detail what new feature you want to see in Jitsi. After we examine its feasibility and decide whether it can be included in the Jitsi distributions you would like be asked to open a ticket in the java.net JIRA Tracker (java.net login required). It is worth mentioning though, that handling feature requests is highly dependent of the developers’ availability and there is no guarantee that all requests will be satisfied.

§ How do I subscribe to mailing lists?

To subscribe to one of the lists, you can send an email to listname-subscribe@jitsi.java.net. Please visit Mailing Lists page to learn more about Jitsi’s mailing lists.

§ How do I contact the project developers?

You can ask questions concerning usage of the Jitsi on the dev mailing list (Note that the mailing lists are moderated, so, unless you subscribe to them, there may be a delay before your post shows up). For all urgent queries you could also use IRC at irc.freenode.net, channel #sip-communicator.

§ How do I send a patch?

Mail patches to the dev mailing list, with a subject line that contains the word “PATCH” in all uppercase, for example 

 Subject: [PATCH] fix for SDP descriptor in INVITE message

A patch submission should contain one logical change; please don’t mix N unrelated changes in one submission, send N separate emails instead.

The patch itself should be generated from within the project root directory using unified diff format. The following example shows one way to generate it: 

 jitsi$ svn diff > myPatchfile.txt

You should give your patch files meaningful names. For instance if you fix a socket bug in the foo class do not call your patch file “patchfile.txt” but instead call it “foo-socket.txt”.

If the patch implements a new feature, make sure to describe the feature completely in your mail; if the patch fixes a bug, describe the bug in detail and give a reproduction recipe. An exception to these guidelines is when the patch addresses a specific issue in the issues database — in that case, just make sure to refer to the issue number in your log message.

Note that unless your change is about a trivial two-line change, we would probably need you to sign, scan and return back to us a copy of our contributor agreement

§ I would like to update this wiki - what can I do?

Currently, only project developers are permitted to update the wiki. Please send your suggested changes to the dev mailing list.

A wiki page can be updated by appending the string ?action=edit to the current url and refreshing the page. The page will then be displayed with an extra menu line that includes a ‘Page Edit’ item.

If you click on the ‘Page Edit’ item, you will be redirected to a logon page. Enter your developer username and password and you should be redirected back to the original page. Click on ‘Page Edit’ again to access the source content of the page (a quick reference to wiki markup syntax is also displayed).

§ Why can’t I connect to ekiga.net?

NB: the problems described in this section also apply to other providers such as 1und1.de

Short Answer: The ekiga.net SIP servers are configured in a way that prevent Jitsi (and many other SIP user agents for that matter) to register with the service. Please use iptel.org or ippi.com instead.

Slightly Longer Anser: The service at ekiga.net is configured to only accept SIP REGISTER requests that contain a public IP address in their Contact header. This means that registration from Jitsi would fail unless you actually have a public IP address. The Ekiga client circumvents this by using STUN to learn the address and port that have been allocated for the current session. It then uses the pair in the SIP Contact header. This kind of use was common for the first version of the STUN protocol defined in RFC 3489 which was sometimes referred to as “classic STUN”.

The IETF has since significantly reviewed the way STUN should be used. The new version of the protocol is now defined in RFC 5389 which, among other things, advises against the use of STUN as a standalone NAT traversal utility: 

 However, experience since the publication of RFC 3489 has found 
 that classic STUN simply does not work sufficiently well to be 
 a deployable solution.

Today STUN represents one of the tools used by complete traversal mechanisms such as SIP OUTBOUND (RFC 5626) or ICE (RFC 5245). Neither of these includes sending a STUN obtained address in a Contact header.

So, where does Jitsi currently stand on all this? At the of writing, we support the ICE protocol but only use it with XMPP. Use with SIP is likely to come in the near future. The reason we haven’t implemented it yet is that most SIP servers currently open to use over the Internet, use a technique called latching. When such servers detect you are connecting from behind a NAT, they would start acting as a relay, receiving media from your peers and then forwarding it to you (and vice versa). While this is by far the most reliably way of traversing NATs, it does indeed imply some scalability constraints.

ICE on the other hand would only fall back to relaying if no other way was found to connect the two participants. This is why it is considered as a more optimal solution and why it’s also on our roadmap.

Note however that the constraints on ekiga.net would continue preventing Jitsi from connecting even when we do implement support for ICE.

§ Does Jitsi support STUN? (and how about TURN, UPnP and Jingle Nodes?)

STUN, together with TURN, Jingle Nodes, and UPnP, is one of the techniques that Jitsi uses as part of the Interactive Connectivity Establishment ( ICE) protocol to handle NAT traversal for calls made over XMPP.

For its SIP calls, Jitsi currently relies on servers to relay media (a technique also known as latching, which would be the case of the majority of the SIP servers used on the Internet today.

It is likely that ICE support for SIP calls would also be added to Jitsi in 2011 or 2012.

Standalone support for STUN is NOT going to be part of Jitsi. Check out the ekiga entry for more information on the shortcomings of STUN as a standalone NAT traversal utility.

§ I have a few questions regarding ZRTP, SRTP and VoIP security in general. Where can I find some answers?

Check out our ZRTP FAQ.

§ Why does my call stay in the “Initiating Call” status and I can never connect?

A common reason for providers not to respond to calls is that they simply don’t get the INVITE request Jitsi sends to them. A common reason for this, on the other hand, is that, if you are using UDP, the Jitsi INVITE requests may often exceed the maximum allowed packet size (MTU) for your network or that of your server. This is what happens when client support multiple features ;). To resolve the issue you can do one of the following:

  • Disable codecs that you don’t use and keep only those that you know you need. PCMU and G.722 are generally a safe minimum choice for audio and you’d better disable all video codecs, at least while testing. Once you manage to successfully connect you may try re-enabling codecs one by one until you reach the upper limit.
  • User TCP or TLS. If your network supports either of these, that would be a far better option.

§ How does on-line provisioning work?

On-line provisioning is the feature that allows Jitsi to connect to an http URI every time it starts and retrieve a part or its entire configuration there. On-line provisioning is often used by providers to remotely configure the clients they maintain. It can be used to set any property in Jitsi such as the codecs we use, the features that users can manually configure and even protocol accounts.

When requesting its provisioning information Jitsi can transmit any of a number of parameters to the server, like for example: the OS it is running on, user credentials, a unique ID and others. This way the provisioning server can fine-tune the parameters it sends to Jitsi.

For more information, please check our on-line provisioning manual

§ Development topics

§ Is there a port of Jitsi for “Android” ?

Not yet. One will be coming in 2011 or 2012 though.

Update: We will be presenting a prototype on FOSDEM 2012 (February 4 and 5, Brussels, Belgium)

§ The cc-buildloop target of ant fails with the following error message: “Could not create task or type of type: junitreport”.

On some Linux distributions such as Debian, the ant package is actualy subdivided into multiple packages. So when you chose to install junit and ant with the distribution specific package system, don’t forget to install ant-optional too.

§ The cc-buildloop target of ant fails with the following error message: “No test with id=IcqProtocolProviderSlick”.

Have you created your own accounts.properties file in the lib directory? You’ll need to define two ICQ test accounts at least, and preferably some test accounts for the other supported protocols.