Jitsi Meaning

  1. Jitsi is a collection of free and open-source multiplatform voice (VoIP), videoconferencing and instant messaging applications for the web platform, Windows, Linux, macOS, iOS and Android. The Jitsi project began with the Jitsi Desktop (previously known as SIP Communicator).
  2. (Redirected from SIP Communicator) Jitsi is a collection of free and open-source multiplatform voice (VoIP), video conferencing and instant messaging applications for the web platform, Windows, Linux, macOS, iOS and Android. The Jitsi project began with the Jitsi Desktop (previously known as SIP Communicator).

Jitsi Meaning In Urdu

Featured questions (hide)


To start with, we will create a DNS A record for accessing the Jitsi Meet application. Settings are saved on a per contact basis, meaning that users can have different settings for each contact they communicate with through the translation module. Module as a standard OSGi module The service was created first as a standard OSGi module for the first part of the project, trying to keep it as independent as possible from SIP.

§ How do I get the latest Jitsi source code?

You could either clone the Git repository from GitHub (see Retrieving and Building the Sources for details) or use one of the nightly source snapshots (check the Download page).

§ 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 is the user profile directory?

Jitsi’s user profile directory is where Jitsi keeps it’s configuration, logs, etc. Its location depends on the operating system.

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

§ Where do I find the log files?

Jitsi Meet Download

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 (Jitsi→Preferences on OS X), 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. If you need to provide the logs for a GitHub issue, send them to Dev Mailing List and link to the thread in the archive or create a Gist and link to it. Please DO NOT paste the log as a comment.

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

  • Until version 2.2 (and 2.3 nightlies including build 4900)
    • inside the “log” folder in the user profile directory
  • Version 2.4 and newer
    • Windows Vista, 7, 8, 10: “%LOCALAPPDATA%Jitsilog”
    • Windows XP: inside the “log” folder in the user profile directory
    • OS X: ~/Library/Logs/Jitsi
    • Linux: inside the “log” folder in the user profile directory

§ Where is the configuration file?

Jitsi’s main configuration file is called sip-communicator.properties and is in the user profile directory.

§ 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 good.

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

Yes, developers take feature requests into account. Send an email to the development list with a detailed description of the requested feature. After we examine its feasibility and decide whether it can be included in the Jitsi distributions you would likely be asked to open a ticket in our issue tracker. 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?

Please visit the 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 #jitsi.

§ 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

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:

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.patch”.

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 you are describing a change rather than posting one, we would probably need you to sign our contributor agreement as either an individual or a corporation

§ 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 Answer: 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:

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.

Jitsi Meaning

So, where does Jitsi currently stand on all this? At the time 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.

§ Why do I see “ICE failed” errors when trying to make calls.

Jitsi implements a number of NAT traversal methods as described here. In many situations we will be able to setup a call directly between you and other users but in order to be able to reliably establish calls, your XMPP or SIP provider has to provide relaying capabilities such as TURN, Jingle Nodes or . If looking for services that support these you can try jit.si or ippi. Also note that both you and your partner need to have unhindered outgoing UDP access to the Internet or at least to your VoIP service provider. You DO NOT however need to map any port numbers on your home router. At best this is going to have no effect.

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

STUN, together with TURN, Jingle Nodes, IPv6 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.

No back desk chair

For its SIP calls, Jitsi currently relies on servers to relay media (a technique also known as Hosted NAT Traversal or latching, which would be the case of the majority of the SIP servers used on the Internet today. Note that in terms of reliability Hosted NAT Traversal gives the same results as use of ICE. It even works better in some ways because the connection is setup immediately and no time is waisted for gathering candidates and making connectivity checks. The only downside of HNT is that it may put a strain on SIP providers requiring more bandwidth. This could become a problem especially in environments with a high number of all IP high quality video calls.

It is likely that ICE support for SIP calls would also be added to Jitsi in 2014 especially since this would also help with WebRTC compatibility.

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. This can happen 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. In such cases packets may be fragmented by your IP stack and fragmentation for UDP does not always work well in certain networks. This is what happens when a client supports 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.
  • Use 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 part or all of its 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 used, 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

§ Are my chat sessions protected and if so, how?

Jitsi Meaning

Jitsi supports the OTR encryption protocol. OTR stands for Off-the-Record Messaging and once you’ve set it up (i.e. clicked on that padlock icon in a chat window and verified the identity of your contact) it allows you to make sure that no one other than you two can read your messages, not even your service provider. You can find more on the OTR mechanisms here:

§ Should logging be disabled by default when using OTR?

By default Jitsi stores all chats so that if you need any information from them it would always be available. If you would like to disable this behavior you can currently do so by opening Jitsi’s Options/Preferences, selecting the “General” pane and then unchecking the “Log chat history” option near the top. It is also possible to disable chats for specific contacts, to erase their history. An indicator in the chat window makes it aware at all times whether history is on or off while chatting with someone.

OTR protected chats follow the same pattern and some users have expressed concerns that this might be incompatible with their security expectations. Our position on this is that Jitsi’s role is to protect your communication. We also strive to offer usability. The current defaults represent these objectives: most people would prefer for their private communication not to be readable by third parties and most of the time people use Jitsi from personal devices where they are in control of the access policy.

In some cases users may wish for their communications not to be stored locally. This can be the case when using Jitsi on devices that others may also have access to. In such cases users need to be able to easily see whether history is being logged. They would also need to easily turn this off and potentially even erase previous history.

Note however that this subject is entirely different from the encryption one. They are separate measures meant to protect you against separate attacks or problems. We don’t believe that the need for one would necessarily imply the need for the other. We are hence committed to also keeping that separation in the user interface.

§ Force SIP Message support.

Some SIP servers (Asterisk in particular) do not announce the MESSAGE support, despite supporting it. If you enable the account propertyFORCE_MESSAGING, Jitsi will attempt to use MESSAGE for chats, despite your configured SIP server not explicitly announcing this support to connected clients. For example, if your SIP account is [email protected], go to property editor type that in the search field and look for something like

net.java.sip.communicator.impl.protocol.sip.acc0123456789.ACCOUNT_UID with the value SIP:[email protected]

The property to add in that case would be:

net.java.sip.communicator.impl.protocol.sip.acc0123456789.FORCE_MESSAGING with the value true.

§ How to add/edit configuration properties.

You can do so by clicking on Tools→Options (Jitsi→Preferences on OS X), then selecting the �Advanced� tab and opening the �Property Editor� form. There you can search edit/delete or create new properties.

§ Is there an an Android version of Jitsi?

Yes, but it is still in an early alpha stage and further development has been put on hold until further notice. A lot of the user interface is not yet implemented. You can find the apk on the Download page.

§ Is there an iPhone/iPad version of Jitsi?

No. Due to the restrictions imposed by the platform it is highly unlikely this answer is going to change.

§ 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.

A basic installation of Jitsi Meet gets you up and running within shortest time, probably in less than 15 minutes. There are hardly any configuration changes necessary. Most important information is a fully qualified domain name (FQDN), and that's it.

However such a default installation of Jitsi Meet is open. Meaning, that anyone knowing the URL of your server can create a new meeting room and start to have video conferences using your instance and probably causing additional cost.

In this second article on Jitsi Meet we are going to enable authentication to avoid any misuse from public users. Please read Install Jitsi Meet on Compute Engine (GCP) in case you have not created your own instance yet.

Securing your instance of Jitsi Meet requires three configuration changes plus the creation of user accounts with permission to host conference calls.

Let's have a look at the architecture of Jitsi Meet to get a better understanding.

It is possible to allow only authenticated users for creating new conference rooms. Whenever a new room is about to be created Jitsi Meet will prompt for user name and password. After the room is created others will still be able to join from an anonymous domain.

Extend the Prosody configuration

The central component of Jitsi Meet is the Prosody XMPP server which is responsible for user management among other tasks, like authentication.

Open the configuration file of your domain with your preferred text editor.

Here you change the current value of authentication from anonymous to internal_hashed like so.

Additionally, you add a new virtual host definition at the end of the same file.


Save the file to confirm the modifications.

Note: The domain of the guest VirtualHost is internal only. It does not require any DNS record or SSL certificate.

The outcome is now that the primary VirtualHost of your Jitsi instance would require any kind of authentication to create a conference meeting room whereas the VirtualHost for guests still grants access to anonymous users.

Add guest domain to Jitsi Meet frontend

After adding the guest domain to the XMPP server component, you need to add this VirtualHost to the configuration object in the web frontend.

Open the config file with a text editor.

Then you add the directive anonymousdomain into your hosts object.

Save and close the configuration file to confirm your modifications.

As you might see in the comment in the hosts sections, it already stipulates that your instance is going to use the new domain for guest users.

Change Jitsi Conference Focus

Next, you have to configure the Jitsi Conference Focus (jicofo) component to allow requests from an authenticated domain only. For that you need to add the protected URL to the properties files. Open it with a text editor.

Add the key-value pair org.jitsi.jicofo.auth.URL=XMPP:<domain> at the end of the file, and save it.

Restart all Jitsi services involved

With all changes mentioned above you need to restart the services to apply all modifications. Run the following commands or restart your VM instance completely.

Check the log files

Should you come across some unexpected issues always have a look at the log files first. Here is a brief overview of where to check.

Create your moderators

For the last step, now that authentication is active, you need to create at least one user which is going to have permissions to create meeting rooms.

According to the architecture it is the Prosody component which is responsible for this part. The command prosodyctl helps you to manage your XMPP server and therefore your user base.

You can add and enable a user with the following command.

The syntax is described here.

Unfortunately, this is not GDPR-compliant, because “enabling users to set their password without the admin knowing it” is a basic and unavoidable security measure.

You completed all necessary steps to enable authentication in your instance of Jitsi Meet. All steps described above are mainly based on the official guide to Secure domain on GitHub.

Let's try it..

Authenticate against your instance of Jitsi Meet

Open a browser and navigate to your URL of Jitsi Meet. The site should load as before and there are no obvious changes visible. Authentication is bound to the creation of a meeting room only.

Either you choose an existing meeting room or you enter a new name and click on GO to start the video conference session. If you are not authenticated the site will now place you in some kind of virtual lobby until a moderator or host arrives.

In case that you are the host of the meeting click on I am the host and you will be asked to enter your credentials. You can either enter just the user name without your domain or the fully qualified user name including the domain - both approaches will work.

Enter your passphrase and click OK. With successful authentication against Prosody the Jitsi Meet component will grant you access to the meeting room and assign moderator permissions to your account.

Public access is still possible as soon as a moderator (host) is present in the meeting room.

As a moderator you will get additional options under Settings > More which allow you to control what should happen when someone enters the meeting room, e.g. being automatically muted or not being visible to other participants.

Enjoy your next, secure video conference.

Consider to set password per meeting room

An additional level of protection against 'Zoom-bombing' or unwanted intrusion into a video conference would be to activate the password of the meeting room.

Click on the i circle in the bottom right area and click on Add password in the popup dialog.

Jitsi Meaning

Enter your room-specific password and hit Enter to confirm your choice.

Jitsi meaning

Note: The password of a meeting room is not persistent and needs to set each time that you would join / start a conference call. You cannot launch a meeting room with an initial password already set.

What's Next?

Perhaps you noticed that the visual appearance of the Jitsi Meet instance running for MSCC looks slightly different to the default installation.


The next article in this series is going to dive deeper into the possibilities to customise the look of your instance of Jitsi Meet.