Howto enable SIP call-in?

Thanks for sharing that info!

What about dialing out?
I mean, I’ve managed to register jigasi on my Asterisk server, so I should be able to dial out, but I can’t. Asterisk receives an empty string and tries to match the “s” priority/extension in the incoming SIP context.
In fact, the jitsi-meet web UI shows me a notification such as " has been invited.", ie., “empty string” has been invited… So I’m guessing that the web application is not sending the number I’m typing over to jigasi.

EDIT: I added a screenshot here: Jitsi-meet and jigasi SIP to Asterisk server

One step at a time. Dialout can probably best debugged on the asterisk side (and I would guess the problem is on that side too)
Using the asterisk cli, you can enable sip debugging for the extension that jigasi is registered on.

Then do something like “core set verbose 5” and "sip set debug peer ".

After that, let jigasi dial out, and watch the asterisk console; take your time and work through it, with these debug infos, you should be able to find the problem.


The log’s below.
The IP addr. of my jitsi-meet server is
4901 is the SIP extension number.
inf-voip is the Asterisk server’s hostname.

The problem I see is that Asterisk tries to look up s in the dialplan’s from-sip-external context.
The “s” priority or extension does not exist in that context.

What I’m wondering is why is it trying to look up “s” instead of the number I typed when I was inviting someone from the web application (the plus sign).

[Apr  1 14:46:21] VERBOSE[1415] logger.c:
<--- SIP read from --->
OPTIONS sip:inf-voip SIP/2.0
Call-ID: 827b26370b99df108d3d33c2a5e83910@0:0:0:0:0:0:0:0
CSeq: 3323 OPTIONS
From: "4901" <sip:4901@inf-voip>;tag=c8423913
To: "4901" <sip:4901@inf-voip>
Via: SIP/2.0/UDP;branch=z9hG4bK-353036-3e5f48a96f05fc52ea925fd77b8897e6
Max-Forwards: 70
Contact: "4901" <sip:4901@;transport=udp;registering_acc=inf-voip>
User-Agent: Jigasi1.1.38-g8f3c241Linux
Allow-Events: refer,conference,remote-control,presence,presence.winfo
Content-Length: 0

[Apr  1 14:46:21] VERBOSE[1415] logger.c: --- (12 headers 0 lines) ---
[Apr  1 14:46:21] VERBOSE[1415] logger.c: Looking for s in from-sip-external (domain inf-voip)
[Apr  1 14:46:21] VERBOSE[1415] logger.c:
<--- Transmitting (no NAT) to --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP;branch=z9hG4bK-353036-3e5f48a96f05fc52ea925fd77b8897e6;received=
From: "4901" <sip:4901@inf-voip>;tag=c8423913
To: "4901" <sip:4901@inf-voip>;tag=as6719373d
Call-ID: 827b26370b99df108d3d33c2a5e83910@0:0:0:0:0:0:0:0
CSeq: 3323 OPTIONS
User-Agent: Asterisk PBX
Supported: replaces
Contact: <sip:>
Accept: application/sdp
Content-Length: 0

This is only a quick-and-dirty solution for dialing out, but thanks to @damencho this works on my site (no Asterisk):
On the Jitsi-Server, file
amended 2 lines:
(though I put in a Let’s Encrypt certificate…)
But inviting works now (of course only in <MyNewStandardRoom>).

So, just to make sure my production Asterisk server (1.4) isn’t the culprit, I decided to install the latest stable Asterisk version available on Debian 9 where I also have Jitsi-Meet & Jigasi.
That would be Asterisk 13 where I configured it as “basic” as possible, listening on port 5061 as port 5060 is already taken by Jitsi. I created two SIP extensions: 4901 (used by jigasi) and 4053 (a softphone I’d like to invite into a jitsi-meet conference room).

Here’s my super simple Asterisk configuration:

# cat /etc/asterisk/extensions.conf
exten = 4053,1,Dial(SIP/4053,300,tTWg)
 same = n,Hangup()

# cat /etc/asterisk/sip.conf



Both SIP extensions seem to be OK:

# asterisk -rx "sip show peers"
Name/username             Host                                    Dyn Forcerport Comedia    ACL Port     Status      Description
4053/4053                                   D  Yes        Yes         A  5060     OK (3 ms)
4901/4901                                  D  Yes        Yes         A  5060     OK (5 ms)

Unfortunately, I was unable to see the above SIP extension 4901 with “status OK” with the default jigasi properties. I had to add PREFERRED_TRANSPORT=udp. Here’s the full config:

# grep -v ^# /etc/jitsi/jigasi/ | grep -v ^$

I then connected to, clicked on the + sign, typed in “4053”, and noticed that the jitsi-meet web UI keeps notifying me that " has been invited" (ie. blank string instead of “4053”). Anyway, I guess that’s a minor bug if and only if the number I dialed is honored.

Now I’m finally getting an error in /var/log/jitsi/jigasi.log that I wasn’t seeing before when connecting to Asterisk 1.4:

2020-04-04 01:22:16.994 WARNING: [82] org.jitsi.jigasi.xmpp.CallControl.checkAuthorized().287 Requests are not secured by JID filter!
2020-04-04 01:22:16.994 INFO: [82] org.jitsi.jigasi.xmpp.CallControl.handleDialIq().211 [ctx=158595613699230988622] Got dial request fromnumber -> 4053 room:
2020-04-04 01:22:17.001 INFO: [82] org.jitsi.jigasi.JvbConference.setXmppProvider().539 [ctx=158595613699230988622] Using ProtocolProviderServiceJabberImpl(
2020-04-04 01:22:17.009 WARNING: [82] org.jitsi.xmpp.component.ComponentBase.log() PROCESSING TIME LIMIT EXCEEDED - it took 17ms to process: <iq type="set" to="" from="" id="lKMaD-260886"><dial xmlns="urn:xmpp:rayo:1" to="4053" from="fromnumber"><header value="" name="JvbRoomName"/></dial></iq>
2020-04-04 01:22:17.235 INFO: [83] impl.protocol.jabber.OperationSetBasicTelephonyJabberImpl.registrationStateChanged().125 Jingle : ON
2020-04-04 01:22:17.236 INFO: [83] org.jitsi.jigasi.JvbConference.registrationStateChanged().577 [ctx=158595613699230988622] Registering XMPP.
2020-04-04 01:22:17.237 SEVERE: [83] impl.protocol.jabber.ProtocolProviderServiceJabberImpl.connectAndLogin().1003 Failed to connect to XMPP service
org.jivesoftware.smack.SmackException: No supported and enabled SASL Mechanism provided by server. Server announced mechanisms: [PLAIN]. Registered SASL mechanisms with Smack: [SASL Mech: GSSAPI, Prio: 100, SASL Mech: SCRAM-SHA-1-PLUS, Prio: 100, SASL Mech: SCRAM-SHA-1, Prio: 110, SASL Mech: DIGEST-MD5, Prio: 200, SASL Mech: CRAM-MD5, Prio: 300, SASL Mech: PLAIN, Prio: 400, SASL Mech: X-OAUTH2, Prio: 410, SASL Mech: EXTERNAL, Prio: 500, SASL Mech: ANONYMOUS, Prio: 500]. Enabled SASL mechanisms for this connection: [ANONYMOUS]. Blacklisted SASL mechanisms: [SCRAM-SHA-1-PLUS].
        at org.jivesoftware.smack.SASLAuthentication.selectMechanism(
        at org.jivesoftware.smack.SASLAuthentication.authenticate(
        at org.jivesoftware.smack.tcp.XMPPTCPConnection.loginInternal(
        at org.jivesoftware.smack.AbstractXMPPConnection.login(
        at org.jivesoftware.smack.AbstractXMPPConnection.login(
2020-04-04 01:22:17.268 WARNING: [87] org.jivesoftware.smack.roster.Roster.processStanza() Roster not loaded while processing Presence Stanza [id=9aD0m-38,type=error,]
2020-04-04 01:22:17.270 SEVERE: [83] org.jitsi.jigasi.JvbConference.registrationStateChanged().581 [ctx=158595613699230988622] XMPP Connection failed.

# cat /etc/prosody/conf.d/
VirtualHost ""
        authentication = "ldap2"
-        ssl = {
                key = "/etc/prosody/certs/";
                certificate = "/etc/prosody/certs/";
        -- we need bosh
        modules_enabled = {
            "ping"; -- Enable mod_ping

        c2s_require_encryption = false

Component "" "muc"
    storage = "null"
    --modules_enabled = { "token_verification" }
admins = { "" }

Component ""
    component_secret = "czzEeVRH"

VirtualHost ""
    ssl = {
        key = "/etc/prosody/certs/";
        certificate = "/etc/prosody/certs/";
    authentication = "internal_plain"

Component ""
    component_secret = "lqrfPXSD"

VirtualHost ""
    authentication = "anonymous"

Component ""
    component_secret = "ivqzsJSh"

Any ideas?

I finally got it working somehow.

I used this for jigasi:

I don’t quite understand what USE_SIP_USER_AS_XMPP_RESOURCE means.

In any case, isn’t there a way to allow jigasi to connect to xmpp without authentication while enabling authentication for the main virtualhost? I’m using LDAP for authentication, and these users must periodically renew their credentials. I don’t want to use an LDAP user for jigasi… I have zero experience with Prosody. I’ve tried adding anonymous to the callcontrol component like so:

Component ""
    component_secret = "jigasisecret"
    authentication = "anonymous"

but it doesn’t seem to work.

Any suggestions?

EDIT: Never mind. I used a special LDAP/AD user for jigasi. I guess I’ll keep it that way.
What would really be useful to everyone is a publicly writable wiki periodically reviewed/edited by the Jitsi devs so that user contributions can be stored in just one place and easily searched for. The forum has interesting findings, but they are dispersed. The official documentation is fine but lacks quite a few things. The user-contributed docs would really help people out.

1 Like

I have a very similar problem, when I run the secure domain jigasi does not connect to XMPP
org.jitsi.jigasi.JvbConference.registrationStateChanged().581 [ctx=15862572610601744470295] XMPP Connection failed.

Hi @Vieri_Di_Paola, @DanielAudio

Don’t know if this helps in your specific situation, but we spent days trying to figure out why jigasi couldn’t authenticate to the XMPP prosody server. In our case, this was also preventing us from being able to call outbound.

Here’s the fix we used to resolve the issue:

In /etc/jitsi/jigasi/, uncomment or add the following lines.

# If you want jigasi to perform authenticated login instead of anonymous login
# to the XMPP server, you can set the following properties.
# org.jitsi.jigasi.xmpp.acc.USER_ID=SOME_USER@SOME_DOMAIN
# org.jitsi.jigasi.xmpp.acc.PASS=SOME_PASS
# org.jitsi.jigasi.xmpp.acc.ANONYMOUS_AUTH=false


where the above USER_ID and PASS are also the same used to create the JIGASI user in prosody by using the command:

sudo prosodyctl register JIGASI YourFQDN PlaintextPassword

After doing the above and for the config changes to take effect restart, prosody, jocofo, jigasi and jitsi-videobridge2 with the following commands:

sudo systemctl restart prosody
sudo systemctl restart jicofo
sudo systemctl restart jigasi
sudo systemctl restart jitsi-videobridge2

Hopefully this helps!

1 Like

We are still however unable to get inbound calling to work with our SIP provider. It appears that the issue is caused by “No JVB room name provided in INVITE header”.

Here’s what we see in the jigasi log:

jigasi_1 | Jigasi 2020-04-18 21:41:15.549 INFO: [264] org.jitsi.jigasi.SipGateway.incomingCallReceived().196 [ctx=15872604755491484561672] Incoming call received…
jigasi_1 | Jigasi 2020-04-18 21:41:16.551 INFO: [265] [ctx=15872604755491484561672] No JVB room name provided in INVITE header

Unfortunately, we do not have the ability to configure the INVITE header at our SIP provider.

When we try to set a default JVB room name ( ‘org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME’ config property) as per the documentation, this however makes no difference. Jigasi just immediately hangs up. So setting the default JVB room name appears to be broken in the current implementation of jigasi.

Is anyone else able to get inbound calling to work correctly by setting the default room name property, in lieu of having to set the room name in the INVITE header?

Thanks much!

(As per documentation at

Jigasi will register on your SIP server with some identity and it will accept calls. When Jigasi is called, it expects to find a ‘Jitsi-Conference-Room’ header in the invite with the name of the Jitsi Meet conference the call is to be patched through to. If no header is present it will join the room specified under ‘org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME’ config property. In order to change it, edit ‘jigasi-home/’ file.


We finally managed to get inbound calling working by only setting the org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME property, w/o setting the INVITE header. The default room name property appears to be case-sensitive. The default room name must precisely match (upper and lower case) the room name that was used to create the meeting by the moderator.

However, now we have another issue. If the room moderator sets a password on the default room, an inbound caller can’t join the room, since there is no way for the inbound caller to enter a password.

Checking the jigasi log, we now see:


2020-04-19 17:31:52.350 SEVERE: [1254] org.jitsi.jigasi.JvbConference.joinConferenceRoom().701 Failed to join chat room […] with nickname: 171945ace5d. The chat room requests a password.


This isn’t the behavior we want. Is there a way to configure Jigasi to allow inbound callers to join the room even if the moderator has set a password on the room?

I suppose, the standard procedure could be to first allow all callers that will be joining the meeting to first call in and connect, and then the moderator can set the room password. Doing this then locks the room and prevents anyone else from being able to join the conference once the room password has been set. A moderator could then remove the room password to admit other callers to join the room, but this would be real pain, especially if callers get disconnected and need to call back in during a meeting in progress. If the room password is set, then they aren’t and won’t able to call back in.

So again, is there any way to configure Jigasi to allow inbound callers to join the room even if the moderator has set a password on the room?

1 Like

You need to send the password via SIP header.
This can be achieved by creating an IVR to collect the password from the caller (if one exists) then , add the password SIP header and pass the call to Jigasi.

1 Like

That’s not possible without custom programming by our SIP provider, nor would we want to hard-code the password for security reasons.

So again, I presume there isn’t any way to configure Jigasi to allow inbound callers to join the room when the moderator has set a password on the room?

No, you need to implement an IVR to ask user for password and send it as a header, otherwise this breaks the security and there is no point of having a password.
If you cannot do it on your sip provider, then you will need asterisk or freeswitch to implement your IVR asking for room Id and password and set the sip headers.

1 Like

You wouldn’t hard code the password. The IVR would ask the caller for the password. Then the user enters a password, the IVR adds the entered password as a SIP header and passes the call onto Jigasi. If the caller entered an incorrect password into the IVR , then they’re denied and the call is dropped.

This assumes you have access to the PBX, otherwise your options are limited in general with SIP integration.

Well that makes perfect sense. Thanks for the technical clarification @Craig_Eustice and @damencho. It’s very helpful.

We have at the moment two separate private Jitsi-Meet instances with Jigasi/Jibri setup for testing and running on two different VMs, One is running the the non-Docker quick install, and the other is running the Docker quick-install. Unfortunately, I don’t have much experience with SIP or XMPP messaging but this is changing rapidly as we’ve been asked to help medical first-responders setup secure remote video conferencing systems here in NYC. Jitsi is truly an extraordinary platform, especially in light of some of the security/privacy issues that have surfaced with other platforms, and we are very grateful for the existence of

Regarding the Jitsi instance running on Docker, how does one set the default JVB room name to enable inbound calling without having to set the INVITE header or hack the docker-composed, auto-generated config files? There doesn’t appear to be a .env variable defined that enables one to set this default JVB room property.

Also, would be deeply appreciative of any guidance on how to setup either a freeswitch or asterisk-based SIP client front end for our various Jitsi/Jigasi installs to configure some kind of auto-attendant/room routing capability. To be clear, we generally do not have access to our SIP provider’s server-side settings, so hence we need another way to control the INVITE headers.

Any advice or technical guidance on this is very deeply appreciated.

I don’t use the Docker version, but are you saying neither version connects or just the Docker version?

For me , I simply changed the default siptest line in file: /etc/jitsi/jigasi/

to read: org.jitsi.jigasi.DEFAULT_JVB_ROOM_NAME=videoconference1

I also had random XMPP issues until adding:

Yes, we’re only running into an issue with Docker version instance. There doesn’t appear to be a way to set the default JVB room property like in the non-Docker version, without hacking the auto-generated config files, which doesn’t seem to work because of the way the Docker containers initialize using docker-compose -f docker-compose.yml -f jigasi.yml up. I guess we could hack these init files, but we don’t want to break anything.

If they are just VM’s at this stage… I’d personally ditch the docker version and duplicate the working VM, hopefully you saved a snapshot prior to setting the hostname.

I’ve had a super easy experience using the standard install on Ubuntu along with FreePBX for the SIP side.

So is the general idea to setup and run a FreePBX or Asterisk server as a SIP client agent that registers on a SIP provider provided extension, and then to configure this to allow one to select different JVB rooms as well as to enable the entry of a room’s password?

That’s the case for me, but I already had a PBX with several DID’s in operation for voice conferencing. So, Jitsi was just a nice addition to our workflow.

If you do go that route, I highly recommend FreePBX. I’ve used a few flavors of IPPBX’s in the past, but FreePBX feels the most intuitive and well documented in my opinion. Lots of videos and guides floating around youtube as well.